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LDAP, LDIF 
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k "Hai lIstorm 


Tizedik kiadott lapszámunkhoz érkeztünk e má- 
jusi számmal, s az ,ojság" (ahogy a levelezési 
listákon említeni szokás) igen szép statisztikák- 
kal dicsekedhet átlagos olvasottságát illetően. 
Átlagos olvasottság alatt azt értem, hogy nagy 
átlagban minden cikk elolvasódik - de messze 
nem mindegyik hasznosul! Valahogy talán a 
rohanó világ az oka, hogy a szakembereknek 
nincs igazán idejük, vagy idegük el is játszadoz- 
ni mindazokkal a lehetőségekkel, melyeket fel- 
tárunk. Természetesen mindenki 10090-ban befogadja saját 
szűkebb szakterületéhez tartozó cikkeinket, de ezzel csak cél- 
jaink 59o-át értük el. Az , ellenséges" cikkekről -— mondjuk ki 
nyíltan - lepattannak olvasóink. Mit értek , ellenséges" alatt? 
Például egy rendszergazda számára ,ellenséges" cikk egy, a 
Transact SOL mélységeiben bányászó sorozat. Egy fejlesztő 
számára ,ellenséges" cikk az Exchange és az Active Directory 
kölcsönhatását feszegető iromány. 

Célunk, hogy minden magyar informatikusnak megadhassuk 
azt, amit a napi robot nem képes megadni: a kitekintés, a fel- 
fedezés, a hatékony továbblépés lehetőségét. 

Gyakran kérdezik tőlem, hogy nem hiányzik-e nekem az ,igazi" 
munka, egy éles rendszer fenntartásának napi gyakorlata? Hogy- 
hogy van bőr az orcámon szaktanácsot adni olyanoknak, akik nap 
mint nap ugyanazt a témát nyűvik? Ki kell, hogy mondjam: az 
ember problémamegoldó képességét nem a naponta újraindított 
gépek, a naponta begépelt sorok, vagy a naponta visszadugott 
nyomtatókábelek számának növekedése fejleszti, hanem az újra, 
másra való nyitottság. Nemrégiben egy programozó ismerősömet 
sikerült meglepnem néhány fantasztikus újdonsággal a Visual In- 
terdevben - pedig ő egy éve abban fejleszt, én meg még csak 
nem is tartom magam fejlesztőnek, csak bug-gyárosnak. 





Hogyan tovább? 

Megírtuk. Kiadtuk. Elolvasták. Az Önök elégedettségi szintje 
1009-os. A mienk 599. Hogyan lehetne megnövelni az , ellen- 
séges" szakterületek iránti fogékonyságot? Például: 

Hogyan lehetne rávenni egy Exchange gurut, hogy ugyan mé- 
lyedjen már el az XML-ben, vagy akár az LDAP-ban? 

Az élet sodra rákényszeríthet erre a nem kívánatos lépésre, mert 
- fenti példánknál maradva - az Exchange 2000 például elké- 
pesztően sokrétűen használja ki az XML adta lehetőségeket 
(OWA!) , amelyhez előbb-utóbb hozzá kell férnünk, s az LDAP sem 
úszható meg hosszú távon, mert egyszer majd olyan Recipient 
Policyt kell faragni, amit szimpla varázslással nem lehet megal- 
kotni (lásd LDAP, LDIF cikkemet e lapszámban). Például ilyet: 


(5(5(5(5 (mailnickname-r) 

D (](s(objectcategoryzperson) (objectClasszuser) 
D. ( ] (homeMDB-" ) (msExchHomeServerName-t ) ) ) 

D (objectCcategoryzgroup) ) ) ) (objectCcategoryzuser) 


(0 (companyzVelvetHammer ) ) ) 


Nesze nekünk! És ki merné állítani, hogy ez a szörnyű LDAP 
nem gyűrűzik be előbb-utóbb mindenhova? 
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Hogyan lehetne rávenni egy rendszergazdát, hogy ugyan ta- 
nulja már meg a WMI-t, és soha többé nem lenne olyan kérdé- 
se, hogy hogyan kell egy távoli gépen éjjel egykor Disabled-be 
tenni a harmadik hálókártyát (reggel ötkor meg vissza). 

Ehhez már nem elég az élet sodra. A WMI roppant hatékony 
tud lenni, de sajnos a fordulatszám felvételéhez nem elég egy 
WMI lélekelemző cikk. (Mint ahogy az SOL nyelvhez sem biz- 
tos, hogy eljut mindenki pusztán azáltal, hogy olvas a tranzak- 
ció-izolációs szintekről.) 

Valami kell még. Hmmm. Mi is? 


Szép szó 

Ez az. A szép, emberi beszéd! Az hiányzik! Milyen szép is lett 
volna, ha anno elmagyarázza nekem valaki a WMI mögötti ob- 
jektummodell mögötti filozófia mögötti lényeget! A koncep- 
ciót! Hogy az egy más világ! Hogy a WMI objektummodellje 
úgy hierarchikus, hogy közben hálós! Hány felesleges órát 
megspórolhattam volna, ami arra ment el, hogy küszködtem, 
és nem értettem a nyomorultat, mert HÁLÓS! 

Ugyanez elmondható az eddig példaként felhozott SOL nyelv- 
ről is. Akinek újdonság, hogy az SOL halmazorientált nyelv, az 
mindaddig lepattan az SOL-t fejtegető cikkekről, amíg a kez- 
dő lökésen, a filozófiaváltáson túl nincs. 


A megoldás 

A megoldás az általunk eddig is dédelgetett Lifelong Learning 
(LLL) koncepcióban rejlik. Ősztől a NetAcademia Kft. több szin- 
ten, és több témakörben indít délutánonkénti oktatást, ahol 
szakavatott, tűzkeresztségen már átesett oktatók (avagy nagy- 
képűbben: mentorok) segítik az önálló tanulást. Ezek között 
lesz tandíjas, tematikus tanfolyamsorozat (MCP vizsgaelőkészí- 
tő tanfolyamok), de lesz olyan, amelynek belépti díját már ki- 
fizették Kedves Olvasóink az újságelőfizetési díj átutalásakor: 
ezek Mesterkurzus néven futnak majd. Tudom, rohamosan kö- 
zeleg a nyár, de talán egy (két) próbaidőpontot elbír még a ta- 
vasz, május és június hó folyamán találkozzunk egy-egy 


NetAcademia Mesterkurzus 


keretében, ahol a lepattanó cikkeket passzolja vissza mandíner- 
ből azok szerzője, hátha második körben már fejbetalál ;) Ezek 
az alkalmak minden előfizetőnk számára ingyenesek lesznek. 

A NetAcademia Mesterkurzusokra szándékaink szerint minden 
hónap utolsó péntek délutánján, 2-től 6-ig kerülne sor, melyre 
szeretettel meghívjuk minden Kedves Olvasónkat. A Mesterkurzus 
ötlete oly friss, hogy e cikk megírásakor nem állt rendelkezésem- 
re pontos helyszín, időpont és tematika sem, ezekről az újság bo- 
rítékjában elhelyezett szórólapokon szerezhet tudomást. 


A Lifelong Learning project keretében pedig ősszel indítunk 
MCP vizsgaelőkészítő esti kurzusokat azok számára, akiknek a 
munkanap nem áldozható fel a tanulás oltárán. 


Fóti Marcell 
marcellf onetacademia.net 
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HÍREK..HÍREK..HÍREK 





Nem lesz SP7 

... legalábbis a Windows NT 4.0-hoz [1]. A hónap egyik 
legfontosabb híre, hogy a Microsoft felfüggesztette a Win- 
dows NT 4.0 Service Pack 7 fejlesztését. Az indoklás szerint 
az utóbbi időben a javítások száma folyamatosan csökkent 
(no meg jön az új oprendszer - (mICK]J), ezért az újabb ja- 
vítócsomagra már nem lesz szükség. A - most már biztosan 
utolsó - SP6a óta megjelent biztonsági javítások összecso- 
magolása mellett a felhasználók által várt két legfontosabb 
dolog a Directory Services Client [2], valamint a nemzetkö- 
zi High Encryption verziók [3] - ezek már külön-külön is 
elérhetők. Az első probléma nyitott maradt, ezért a harma- 
dik negyedévben (az SP7 eredetileg tervezett megjelenése- 
kor) megjelenik majd egy, az SP6a-ra telepíthető, biztonsá- 
gi javításokat egyben tartalmazó upgrade csomag. 


Windows 2002 

A Whistler Server végleges neve Windows 
2002 lesz - jelentette be a Microsoft április 
30-án [4]. Bár a - legújabb hírek szerint - 
októberben megjelenő Windows XP és az őt valamikor 2001 el- 





AdAstra 


ső negyedévében követő kiszolgálócsalád, a Windows 2002 
egy tőből fakad, a Microsoft továbbra is megkülönböztetni lát- 
szik a felhasználói és kiszolgálói oldalt. A Windows 2002 jelen- 
leg - az XP-hez hasonlóan - béta 2 állapotban van, de az XP- 
vel ellentétben a Windows 2002 megjelenése előtt még egy 
béta 3 verzió készül majd. 


Kirúgták az Office segédet 

Az Office Segéd, más néven Clippy, a 
sokunk által (nem) kedvelt bajkeverő 
nyugdíjba vonul. Az Office 97-ben 
megjelent segéd eddig folyamatosan 
jótanácsaival látott el bennünket, mire végre megtaláltuk a 
módját, hogy eltüntessük az útból szegényt. (Az Office 
2000-ben ezen a területen fejlődött egyébként a legtöbbet a 
dolog). Az Office XP-ben (eX-Paperclip) a segédek már csak 
külön kívánságra bújnak elő, ha valaki mégis hiányolná 
őket. A Microsoft sokmillió dolláros kampányba kezdett [5], 
ami Clippy kirúgásáról szól - a kampány eszmei mondaniva- 
lója az, hogy az Office XP használata már olyan egyszerű, 
hogy nincs többé szükség a Segédek közreműködésére. 


Thatts right, 
fve been 
demoted! 





A cikkben található URL-ek: 


[1] http://www.microsoft.com/ntserver/sp7.asp 

[2] http://www.microsoft.com/windows2000/news/bulletins/adextension.asp 
[3] http://www.microsoft.com/windows/ie/ 

[4] http://www.microsoft.com/presspass/features/2001/aprO1/04-30w2k.asp 
[5] http://www.officeclippy.com 
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Ezzel a cikkel nem kevesebbet vállaltam, minthogy egyszer s 
mindenkorra mindenkit átrugdalok az LDAP vizsgán, hisz az 
Active Directory már évek óta velünk van; nem rendszergazda 
a rendszergazda, ha nem ismeri saját rendszerét! Ráadásul 
amint egyre több címtáralapú alkalmazás születik (Exchange 
2000, ISA stb.), mindennapi munkánk során is egyre gyak- 
rabban fogunk belebotlani az átkozott(nak tűnő) LDAP filte- 
rekbe. Lásd Exchange 2000 Recipient Policies. Van azonban 
ennél földhözragadtabb példám is... 

Levelezési listáinkon merült fel egy igen érdekes igény a Win- 
dows 2000 Active Directoryval kapcsolatban: vajon hogyan le- 
het egynél több felhasználón egyszerre megváltoztatni vala- 
milyen beállítást - mondjuk a home könyvtárat? A régi, bevált 
NT4-es módszer ugyanis (sok felhasználó együttes kijelölése 
a User manager-ben, és a Properties menüpont kiválasztása) 
nem működik az Active Directory Users and Computers eszköz- 
zel! Amint ugyanis egynél több felhasználót jelölünk ki, a 
Properties menüpont egyszerűen eltűnik. 










Description 





Add members to a group... 








e. User Disable öccount 
Enable Account 
userd User Move... 

Exchange Tasks.. . 
FE useró User Open home page 
Send mail 

Fo users User HT 
2 user9 User All Tasks 

fs usera User gye 

3 userB User 

főz userc User 


User 





E serD 


5 Több objektum egyidejű kijelölése esetén NINCS Proper- 
ties menüpont! 


Hja kérem, a fejlődés megállíthatatlan. Más baj is van: ha 
nem egyazon 0U-n belül szeretnénk válogatni, a hierarchikus 
felépítés miatt a csoportos kijelöléssel áthághatatlan egér- 
akadályokba ütközünk. 

Sok érdekes és előremutató megoldási javaslat elhangzott, 
írjunk ADSI script-et (erről tavaly októberi számunkban ol- 
vashattak részletesen), vegyünk X dollárért külső szoftvert, 
de valahogy az egyik legkézenfekvőbb, legegyszerűbb, leg- 
szabványosabb, ingyenes módszer nem ismeretes a rend- 
szergazdák előtt: export-import! 


Export-import 

Az Active Directory címtára minden további nélkül szövegfájl- 
ba exportálható, és onnan - a megfelelő módosítások elvég- 
zése után - visszaimportálható. Erre kétféle eszköz is létezik: 
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WINDOWS 2000 


a CSVDE.EXE és az LDIFDE.EXE. Parancssori kapcsolóik (szin- 
te) megegyeznek, ám a kettő nem egyenértékű, mindegyik- 
nek megvan a maga szerepe. 


CSVDE 

A CSVDE.EXE nevéből is kitalálható módon (Comma Separated 
Directory Export) vesszővel határolt fájlokkal dolgozik, ami 
rendkívül hasznos, ha az adatokon adatbázisjellegű utófeldol- 
gozást, módosítást szeretnénk végezni. Excel-lel kiválóan ke- 
zelhető, táblázatos kimenetet produkál, amit (jobbára) simán 
vissza lehet termelni a címtárba a módosítások után. Ugyanak- 
kor csak új objektumok létrehozására és (korlátozott) módosí- 
tására alkalmas, törlésre és átszervezésre már nem jó, mivel a 
CSV fájlban csak és kizárólag adatok helyezkedhetnek el, paran- 
csokat belevenni nem lehet. Azért írtam, hogy csak jó esetben 
lehet vele visszaimportálni az adatokat, mert ha nem vigyá- 
zunk, már az exportáláskor belekerül az outputba egy csomó 
olyan adat, amit visszaimportálni nem lehet, mert módosítha- 
tatlan (read only). Ilyen érték például a SID, és a replikációhoz 
tartozó USN értékek. Ezektől úgy lehet megszabadulni, hogy az 
exportáláskor használjuk a -m és -n kapcsolókat, melyek letilt- 
ják a bináris szemét fájlba írását. (A két parancs kapcsolóinak 
teljes körét a cikk végén foglaltam össze.) 


LDIFDE 

Az LDIFDE.EXE ezzel szemben speciális szövegfájlformátum- 
mal dolgozik, melynek felépítése a 2849-es RFC-t követi, s 
amelyben szépen elférnek egymás mellett adataink, és utasí- 
tásaink. Az LDIF valójában az LDAP címtárak közötti repliká- 
ció szabványa, így nem csoda, ha mindenre képes: töröl, mó- 
dosít, objektumot mozgat egyik szervezeti egységből a másik- 
ba, jelszót állít stb. Okos gyerekek tanulnak a University of 
Michiganen! (Ott született az LDIF -a szerk.) Talán emiatt is 
riadnak sokan vissza azonnal ettől a megoldástól, mert ha 
olyan sokat tud, akkor bizonyára halálosan bonyolult. 

A félelem alaptalan, az LDIF fájlok tökéletesen érthetők. 
Annyiban azonban mégiscsak megérthető a viszolygás, 
hogy sajnos nemcsak egy szintaxist kell ismerni a teljes kö- 
rű használathoz, hanem négyet: 

"0 Az LDIF szintaxis ismerete szükséges a fájl elkészítéséhez, 
módosításához (RFC 2849, [2]) 

LDAP Distinguished Name segítségével állítjuk be az ex- 
port/importot a hierarchia megfelelő pontjára (RFC 2253, [3]) 
LDAP keresőfeltétellel válogatjuk le exportáláskor a módo- 
sítani kívánt objektumokat (lengyel jelölés, RFC 2254, [4]) 
És végül itt van még magának az LDIFDE.EXE-nek a sok 
ezer kapcsolója. 

Hmmm. Hol is kezdjem? Legyünk sikerorientáltak, így első- 
ként valami működőképeset mutatok: az alábbi LDIF fájl lét- 
rehozza a , marketingesek" nevű szervezeti egységet a neta- 
cademia.net tartomány gyökerében: 


ks 
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WINDows 2000 LDAP; LBIF 


dn: ousmarketingesek, dcsnetacademia , dc-net 
changetype: add 
objectclass: organizationalUnit 


ou: marketingesek 


Ennyi. Pár sorral lejjebb el is magyarázom, de először lássuk 
a fájlt munka közben! Ha a fenti 4 sort begépeljük Notepad 
segítségével egy közönséges textfájlba, vagy leszedjük az 
LDIF példákat a [1] címről, már importálhatjuk is a címtárba. 
Mentsük el marketing.txt néven, hogy ezzel a névvel elejét 
vegyük annak, hogy bárki a jövőben esetleg belenézzen eb- 
be a fájlba, vagy akár le merészelje törölni (bűvös fájlnév!) . 
Felhívnám Kedves Olvasóim figyelmét arra a könnyen belát- 
ható, ámde szomorú tényre, hogy nem minden vállalatnál 
netacademia.net a tartomány neve, így ezen hivatkozást 
(dcznetacademia,dc-net) a teljes siker érdekében érdemes 
átírni próbaképpen a vállalatnál használt tartomány valódi 
nevére (például dcsvallalat,dc-hu vagy ami éppen a valóság) . 
Beimportálni így kell: 


LDIFDE -i -f marketing.txt 


Ezzel az aktuális bejelentkezett felhasználó nevében a legköze- 
lebbi tartományvezérlőhöz csatlakozva az LDIFDE.EXE import 
módban lefuttatja parancsfájlunkat. További kapcsolókkal meg 
lehetne változtatni a biztonsági jellemzőket (névijelszó) , illet- 
ve kiszolgálót lehet váltani, de ezekre később térjünk ki részle- 
tesen. Most valami ilyesmit válaszol a program: 


E:Vldifde -i -f a.txt 

Connecting to "platan.netacademia. fm" 
Logging in as current user using SSPI 
Importing directory from file "a.txt" 
Loading entries.. 


1 entry modified successfully. 
The command has completed successfully 


Ellenőrizzük, hogy igazat mond-e, nézzük meg az Active Di- 
rectory Users and Computerssel, hogy létre jött-e , Marketin- 
gesek" nevű 0U. Ha nem, annak a következő okai lehetnek: 
1) Elgépelés. Megfelelően félregépelt ,dn" segítségével 
akár még LDAP referralt is kaphatunk: 
The error is "A referral was 


server side 


returned from the server." 
de könnyen előfordulhat ilyen válasz is: 


There is a syntax error in the input file 


Failed on token starting with "d" on line 4 


2) Jogosultsághiány. Az éppen aktuálisan bejelentkezett 
felhasználó erejével fut a fenti parancs! 

3) DNS hiba. Minden Active Directory hiba oka a DNS-ben 
keresendő! 

Most vizsgáljuk meg a parancsfájlt sorról sorra! 
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LDAP útvonalak 

dn: ou-marketingesek,dc-netacademia,dc-net 

A "dn" az X.500 szabvány szerinti megkülönböztető név (Disting- 
uished Name, RFC 2253, [3]) rövidítése, amely egy címtárobjek- 
tum teljes címtárazonosítója, olyasmi, mint a fájlrendszerben 
egy fájl teljes útvonala (például C: ladatok (fontos. doc) . 

A fájlnévhasonlat több okból is telitalálat. Egyfelől a "dn"-nek 
éppúgy globálisan egyedinek kell lennie, mint egy teljes út- 
vonalnak, másfelől éppúgy leválasztható róla az objektum sa- 
ját neve (rdn, Relative Distinguished Name), mint ahogy az 
útvonalból kiolvasható a fájlnév. Továbbá mindaddig lehet- 
nek a címtár különböző pontjain azonos nevű objektumaink, 
amíg egy , könyvtárban" nincs két egyforma nevű (mint ahogy 
ezer különböző könyvtárban lehet readme.txt nevű fájl, de 
egy adott könyvtárban egyszerre csak egyetlenegy fér meg). 
Magának a "dn" útvonalnak a szintaxisa sem túl bonyolult. 
Éppúgy balról jobbra dolgozunk vele, mint a DNS tartomány- 
nevekkel, jobbról balra a meghatározás egyre szűkebb. Az RFC 
szerint a következő útvonalazonosítók léteznek: 


Azonosító — X.500 attribútum 


CN .— commonName 
L — localityName 

ST — stateOrProvinceName 
0 — organizationName 


OU — organizationalUnitName 
C — CountryName 
STREET streetAddress 
DC — domainComponent 
UID userid 


A következő gyakori útvonalazonosítókkal találkozunk a Win- 

dows 2000-ben (a többivel én speciel még nem találkoztam) : 

"8 DC, Domain Component, tartományösszetevő. A tartomá- 
nyunk nevét adjuk meg ezzel a kulcsszóval, mégpedig úgy, 
hogy a tartomány DNS nevét tagonként felcímkézzük. Azaz 
ha a tartomány neve kukutyin.hu, akkor az X.500 útvonal 
így fest: DC-kukutyin,DC-hu. A DNS név és a DC hasonló 
felépítése nem véletlen, ez a szócska az átjáró az X.500 és 
a DNS világ között. Ha ugyanis címtárhozzáférésünk során 
nem adunk meg kiszolgálónevet (ahogy a fenti példában 
sem), akkor a Windows a DC összetevők visszafejtése ré- 
vén nyert DNS tartománynév alapján keresi meg a célba 
vett domaint - mégpedig DNS lekérdezéssel! 

2 OU, Organizational Unit, szervezeti egység. A tartománybel- 
ső hierarchiájának leírására való. Ha egymásba ágyazott 
szervezeti egységeink vannak, azokra így tudunk hivat- 
kozni: 0U-legalul 0U-kozepen, 0U-legfelul. Érdekes je- 
lenség, hogy az Active Directory telepítésekor megje- 
lenő tárolók többsége nem OU, nem valódi, hanem ál- 
konténer, így nem 0U-ként hivatkozunk majd rájuk, ha- 
nem CN-nel. Az alábbi ábrán egy tartomány alapértel- 
mezett, és utólag létrehozott konténereit láthatjuk. A 
valódi 0U-k ikonja könyvecskés, az álkonténereké sima. 
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o Amelyik OU ikonja nem ,,könyvecskés", az valójában 
nem is 0U 


2 CN, Common Name, objektumnév. Ez a szócska az úgyne- 
vezett Relative Distinguished Name megjelölésére szolgál. 
Ezzel azonosítjuk az objektumokat (CN-Kis Pista, CN-Sen- 
ki Alfonz stb.). Az Active Directoryban felhasználók és 
egyéb hétköznapi objektumok mellett rendszeradatokat is 
találunk (CN-Configurarion, CN:-Schema és így tovább), 
ezeken túlmenően az álkonténereket is hasonlóan címez- 
zük (CN-Users, CN-Computers stb.). 

Így a Falatrax cégnél dolgozó Kovács felhasználó, ha a Users 

tárolóban van: 


CNsKovács , CNsUsers , DCsfalatrax, DC-hu 


azonban ha a marketingesek szervezeti egységben he- 
lyezkedik el: 


CNsKovács , OUsMarketingesek , DC-falatrax, DC-hu 


LDIF módosítások 

Egy lépessel közelebb kerülhetünk a végső célhoz, ha megkí- 
séreljük módosítani egy meglévő felhasználó valamelyik ada- 
tát - mondjuk az Administrator fiók Description mezőjét. A 
következő LDIF fájl lesz a segítségünkre: 


dn:CNsAdministrator, CN-Users , DCsnetacademia, 
4 Dcsnet 

changetype: modify 

replace: description 

description: blablabla 


Ez sem lényegesen bonyolultabb az előzőnél, s beimportálni 
is ugyanúgy kell. Azonban itt már látszik, hogy az LDIF szin- 
taxist is tanulni kell. Az utolsó sorban a mínuszjel nem vélet- 
lenül van ott, hanem a parancs lényeges része. Az LDIF fájl 
általános felépítése a következő: 

dn: útvonal 
changetype: parancs 
adatok 
cüres sors 

dn: útvonal 
changetype: parancs 


adatok 
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Az útvonal szerencsére már a markunkban van. A changetype 
sorban a következő parancsok szerepelhetnek: 

add, delete, modify, modrnd, moddn 

Ezek közül a két utolsó átnevezésre és átszervezésre való. A 
modify parancs kivételével az adatsorok folyamatosan követik 
egymást. Azonban a modify különleges, mert egyetlen módo- 
sítás során egy adott objektum több attribútumát egyidejűleg 
kezelhetjük: törölhetünk, felülírhatunk, vagy újat vehetünk 
fel. Ezeket az alparancsokat választja el a kötőjeles sor. Az 
alábbi példában egyszerre cserélem a description mezőt, tör- 
löm a telefonszámokat és beállítom a dolgozó főnökét: 


dn:CN-Valaki, OU-Marketingesek , DC-netacademia , DC-net 
changetype: modify 

replace: description 

description: blablabla 


delete: telephoneNumber 


add: manager 
manager : CN-senki , OU-Marketingesek , DCnetacademia , DC-net 


Most próbáljuk ki a changetype:add parancsot, és hozzunk 
létre egy új felhasználót! 

dn: CN-Hapsi,DCsnetacademia, DC-net 
changetype: add 

objectclass: user 


SamAccountName: Hapsi 


Nem igényel túl sok kötelező paramétert ugye? Se jelszó, se 
semmi! Ha leellenőrizzük Hapsit, láthatjuk, hogy létrejött a 
domain gyökerében, ám tiltott (Account Disabled) állapotban 
leledzik, erről árulkodik a piros jelecske:  f25Hapsi User 
Próbáljuk őt engedélyezni, vagy beállítani a homekönyvtárát, 
vagy bármely más attribútumát, természetesen LDIF-fel! Itt 
súlyos akadályba ütközünk: mindent tudunk a módosítás mi- 
kéntjéről, de vajon mi a kívánatos attribútum LDAP neve? Mit 
írjunk az LDIF fájlba? 


A címtár felfedezése 

Természetesen az volna a legjobb, ha valamilyen kipróbált 
módszerünk lenne a címtár részletes kilistázására, ha lenne 
olyan eszköz, mely hasonló részletességgel tárja fel az Active 
Directoryt, mint ahogy a rendszerleíró adatbázist a regedt32.exe. 
Van ilyen eszköz, mégpedig ingyen! A Windows 2000 CD-n, a 
VSupportNools könyvtárban található mini Resource Kit sok 
hasznos csecsebecse mellett tartalmaz nem is egy, hanem 
mindjárt két címtártúrót, az ADSIEditet és az LDP.EXE-t. E ket- 
tő közül az ADSIEdit felhasználói felülete a barátságosabb, 
ezért sokan azt hiszik, az a hasznosabb. A teljesen fapados 
LDP.EXE-nek azonban megvan az az óriási előnye, hogy soha- 
sem hazudik. Az Active Directory rendkívül takarékosan bánik 
a tárolóhellyel: ha egy objektum egyik attribútumát (például 
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egy felhasználó telefonszám mezőjét) nem töltjük ki, akkor 
nem is tárol ilyen nevű mezőt, azaz a user-nek mindaddig 
egyáltalán nincs telefonszám-attribútuma az adatbázisban, 
amíg ezt a mezőt ki nem töltjük. Az LDP.EXE hűen tájékoztat 
a valóságról, míg az ADSIEdit az Active Directory séma alap- 
ján odahazudik egy üres attribútumot, amint az az alábbi áb- 
rán is látszik. Emiatt az LDP-t választjuk. 


CN-Hapsi Properties Mo 


Attibutes ] Security 


2]x 


Path: LDAP://platan.netacademia.Ím/CN:-Hapsi DCsnetacademia DC- 
Class: user 


Select which properties to view: . [Optional z 


Select a property to view 





— Attibute Values ————————— —— 


Í i ési 
[DirectoryString ! 


Syntax I 





a Hapsinak egyáltalán nincs telephoneNumber attribútu- 
ma, az ADSIEdit mégis úgy mutatja, mintha lenne. 


Fapados, puritán felhasználói felülete a gyakorlatlanabb rend- 
szergazdákat elbizonytalanítja, nagyon-nagyon sokan képte- 
lenek használni ezt a csodaeszközt, pedig milyen egyszerű! 
Ha ismerjük az LDAP protokoll működését, az LDP.EXE menü- 
pontjai ismerősnek tűnnek. Nem más ez az eszköz, mint az 
LDAP protokollra épített példaalkalmazás, ezt az érzetet erő- 
síti a kidolgozatlan felhasználói felületen kívül a tökéletes 
protokollhűség. A munka megkezdése előtt ugyanis kapcso- 
lódnunk kell egy LDAP kiszolgálóhoz (Connect) , majd a meg- 
felelő jogosultság megszerzéséhez létre kell hoznunk egy 
címtárkötést (BindReguest) , s ezután következhetnek a cím- 
tárműveletek (például keresés, SearchReguest) . Szerencsére 
e három lépésen az alábbi ábrák tanúsága szerint üres abla- 
kokon keresztül vezet az út, s így a DNS-ből kiválasztott ki- 
szolgálón, az éppen aktív felhasználó jogosultságaival a tar- 
tomány gyökerébe jutunk. Indítsuk el az LDP.EXE-t, és az 
alábbi módon NE töltsük ki egymás után a Connection/Con- 
nect, majd Connection/Bind, végül a View/Tree menüpon- 
tokra megjelenő ablakokat: 
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ez 1 


Connect 


Sr stét] (ener 1 fi 





szi Pot [389 TT Connectionlesz 
Save 
si — See ] 





5 Ha nem adunk meg kiszolgálónevet, az eszköz DNS le- 
kérdezéssel keres LDAP kiszolgálót 


A fenti ábrán szépen látszik a fapados jelleg: a 
.Connectionless" felirat nem fért be az ablakba. Oda se neki! :) 
A sikeres kapcsolatfelvétel (Figyelem! Még nem jelentkez- 
tünk be!) után a jobboldali panelen visszakapjuk az LDAP 
gyökér információit (RootDSE), mely tájékoztat ezen címtár 
által kiszolgált névterek (naming context) elérési útvonalá- 
ról. Ismeretlen címtárak esetén ez az infó teszi lehetővé, 
hogy akkor is megtaláljuk az adatokat, ha esetleg a tarto- 
mány nevét sem ismerjük. 

namingContexts: CN-Schema, CN-Configuration, 

3, pCsnetacademia, DC-fm; 

4 CN:-Configuration, DCscnetacademia, DCsfm; 

3 Dcsnetacademia , DCsfm; 

defaultNamingContext: DCsnetacademia, DC-fm; 
schemaNamingContext: CN-Schema, CN:-Configuration, 
4 DCsnetacademia, DCsfm; 
configurationNamingContext: CN-Configuration, 

4, Dcsnetacademia, DCsfm; 


rootDomainNamingContext: DC-netacademia, DC-fm; 


A következő két lépésben rákapcsolódunk az egyik névtérre, 
amihez viszont már be kell jelentkeznünk: 


L., [daps://platan.netacademia.-fm/DCs 






[7 Domain: 
INTLMAKerberos) 





5 Ha nem adunk meg nevet és jelszót, az aktuális felhasz- 
náló nevében csatlakozunk 
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Connection  Browse ! view Options  Utilties 


zIDI2 





portedCapabilities: a] 
4.800; 





7 


5 Ha nem adunk meg névteret, a tartomány gyökeré- 
be jutunk 


NUM 


Három üres ablak, és máris miénk az AD! 

Ezután már gyerekjáték megtalálni egy-egy objektum valódi 
nevét. Nézzük meg például kedvencem, a tulajdonságlapo- 
kon Office néven szereplő mező valódi nevét. Ehhez kitöl- 
töm a mezőt az Active Directory Users and Computerssel 
(mert ha nem tölteném ki, nem is látszana az LDP-vel) , majd 
megkeresem ugyanezen objektumot LDP.EXE-vel, és a jobb 
panelen olvashatóvá válik az attribútum belső, scriptekben 
használatos neve: 


PhysicalDeliveryofficeName 





TESTE 2]x 
MemberOf — ] — Diakin — ] Environment — ] 0 Sessions] 
Remote control] Terminal Services Profle  ] — Exchange Features ] 


General ] Address ] Account ] Profe ] Telephones ] Organization ] 


e Hapsi 

First name: l Initials: 
Last name: 

Display name: 

Description: 


Ielephone number: Othet... 


E-maik 
Web page: Other... 





9 Ami az AD-ben Office... 
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MLSZ ESZE E zJOl2d 
Lornedtion Browse Wew Options Utáties 
E DCsnetacademia DCeÍm EI 15 objectGUlD: 2] 
CN:Butn DCsnetacadema OCsfm j5a7eftt-2119-4tf0-B4c1-S3ZZab2g4cáca; 


CNimComosters DCsnetacademta DCefr 
ÖVaDoman Controlers DC mnetacademe 
jefeladatok DCsnetacademia DCsfm 


15 objectSid: 





19 uSNChanged: 276024; 

15 usNCreated: 275970; 

19 whenChanged: 4/19/2001 10:53:52 
entral Europe Standard Time Central Europe 
aylight Time; 

1 whenCreated: 4/19/2001 10:22:47 
entral Europe Standard Time Central Europe 





Oaljsagrok DCenetacadema DC ete 
CNaljsers DCenetacademta DC atm af taylight Time; 
; 





ul 


Ready nm 





a ...az a valóságban physicalDeliveryOfficeName! 


Ezzel kezünkben van annak kulcsa, hogyan tudunk tet- 
szőleges objektumon tetszőleges attribútumot megtalál- 
ni, majd nagy tömegben módosítani LDIF fájl segítségé- 
vel. Itt van például az Account Disabled, amelyet a use- 
rAccountControl attribútum módosításával billenthetünk 
át. Ez egy bitmező, melynek kilencedik bitje engedélye- 
zi a user-t (-512), így ez az LDIF fájl így néz ki: 


dn: CN-Hapsi, DC-netacademia, DC-net 
changetype:modify 
userAccountControl 

512 


replace: 
userAccountControl: 


Hú, de sokat kellett gépelni! Vajon hogyan teszünk szert 
(fél)kész LDIF fájlra, mely már tartalmazza az objektumo- 
kat, hogy csak a módosítást kelljen megírni? Igen, expor- 
tálással, de ha nekem például csak a felhasználók kellené- 
nek egy ou-ból, hogyan válogatom ki? Gyenge megoldás- 
nak tűnik, hogy minden objektumot kilistázunk, majd az 
ömlesztett LDIF fájlból kitöröljük, ami mégsem kell. Inkább 
ne is menjen ki a fájlba! Erre nyújtanak megoldást az LDAP 
filterek, melyek megszabják, hogy egy 0U-n belül mely ob- 
jektumokra vagyunk kíváncsiak. Ez lesz e cikk 23. szintaxi- 
sa, készüljenek, megint valami újdonság jön! 


LDAP filterek, lengyel jelölés 

Az LDAP szűrők szintaxisa még véletlenül sem hasonlít egyet- 
len nap mint nap használt lekérdezőnyelvre sem. Semmi SOL! 
Itt egy olyan őskövülettel találkozunk, melyhez hasonlót 
azok láthattak, aki még a "68-as diáklázadások előtt vásárol- 
tak elektronikus számológépet. Egyik ismerősöm édesapjának 
szomszédjának kollégája mesélte, hogy hallott olyan ember- 
ről, aki látott olyan embert, aki kezében fogott olyan , zseb" 
számológépet, amelyiken nem úgy kellett begépelni a világ- 
megváltó atomfizikus ősegyenletet, hogy 1--1- hanem úgy, 
hogy először jöttek a feldolgozandó adatok (1 és 1), majd a 
műveleti jel (--). Ezek a gépek ugyanis közvetlenül a verem- 
ben dolgoztak, amibe be kellett tuszkolni (push) az adato- 
kat, majd a műveleti jel beütésével azok onnan kipoppolód- 
tak, kiszámolódtak, és a végeredmény visszakerült a sztekkre. 
Az ezen logikát követő jelölésmódot nevezzük FORDÍTOTT 
lengyel jelölésnek. Tehát (2--3)"4 helyett 2, 344" 

Az LDAP filterekben ehhez hasonló, ám nem fordított jelölést 
használunk, ahol elöl áll a műveleti jel, s ezt követik az ada- 
tok. Filterről lévén szó természetesen logikai műveletekre kell 
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gondolnunk, van logikai ÉS (jele: 8) VAGY (jele:]) és NOT (jele: !) 
műveletünk, továbbá egyenlőség, hasonlóság (--), kisebb, na- 
gyobb. Ezekkel a jelekkel, és a megfelelő logikai kifejezésekkel vá- 
logathatjuk ki egy adott szervezeti egységből az összes user-t: 


(objecteclasszuser) 


az összes user-t és csoportot (tehát más objektumokat, pél- 
dául névjegyeket nem): 


(£(objectclasszuser) (objectclasszgroup) ) 


Bámulatos ugye? Próbáljuk ki újdonsült tudásunkat valami 
hétköznapi eszközzel - legyen mondjuk az... Active Directory 
Users and Computers! 
Ennek filterét rajtunk kívül még soha emberfia nem használ- 
ta. Egyszer ezen a teszten is át kell esnie az operációs rend- 
szernek, nem igaz? ;) 


zlojad 
zlölai 






mieoB e [dgazat 


ETETETT zjagjéee LESTE Ti 
Ta € shomaloer at ebjnets bet: 
SZG) € ghomenythelekonígtoet al ebjnetr bet 














5 Mostantól csak a felhasználók és csoportok lesznek lát- 
hatók 


Most szűrjük ki az összes olyan csoportot, ahol a csoport ne- 
ve ,a" betűt tartalmaz: 


(s (objectelasszgroup) (cn-tat) ) 


illetve azokat a felhasználókat és csoportokat, ahol a descrip- 
tion mező ki van töltve: 


(5 (description-t ) ( [robjectclasszuser) 


4 (objectelasszgroup) )) 


Ez utóbbi példa azért helyes, mert amelyik objektumnál nincs 
kitöltve a description mező, ott nincs is meg ez az attribú- 
tum, tehát tartalma sincs, így az nem egyenlő a csillaggal. 
Remélem ezen példák alapján bárki össze tud majd állítani 
tetszőleges keresési feltételt, például ki tudja majd válogatni 
az összes olyan névjegyet, ahol az email cím nincs kitöltve: 


(s(objectclasszcontact) ( ! (mail-r) ) 


A filtereket természetesen bárhol felhasználhatjuk, ahol LDAP 
lekérdezést várnak tőlünk, például az LDIFDE.EXE parancsso- 
rában, ahol azonban fel kell készülnünk arra, hogy a DOS pa- 
rancssor különleges karakternek tekinti a 8. és ] jeleket, ezért 
mindegyik elé " (kalap) jelet kell tennünk, ez ugyanis men- 
tesíti az átok alól az átkozottat. Lassan minden eszköz ren- 
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delkezésünkre áll egy fantasztikusan bonyolult export végre- 
hajtásához, így itt az ideje, hogy a CSVDE.EXE és LDIFDE.EXE 
többi kapcsolójára is kitérjünk. 


CSVDE és LDIFDE kapcsolók 


-i: a importmód bekapcsolása 

-£: az LDIF fájl neve 

-s: kiszolgálónév (ha nem adjuk meg, sebaj) 
-t: portszám (default - 389, SSL-lel 636) 

-d: RootDN, az LDAP keresés gyökere 

-r: LDAP szűrő (az alapértelmezés: 

8 "(objectClasszt)") 

-p: a keresés mélysége (Base/OneLevel/Subtree) 
-1: a kívánatos attribútumok listája 

-o: a nemkívánatos attribútumok listája 

-m: nem kérjük a SAM bináris szemetét (SID, stb.) 
-n: semmilyen bináris szemét nem kell 


-b UserName Domain (Password ] "] 


LDIF hardcore 

Most néhány olyan példa következik, mely egyszerre használ- 
ja az eddigi ismereteket, sőt tovább vezet minket az LDAP - 
LDIF páros alkotó módon történő történő felhasználásához. A 
gyengébb idegzetűek most hegyják abba a cikk olvasását! 


Objektum mozgatása a címtárhierarchiában 

Első példánk legyen Hapsi átmozgatása a tartomány gyökeré- 
ből a marketingesek 0OU-ba. Ehhez Hapsit ki kell exportálni, de 
úgy, hogy CSAK hapsit, és annak is CSAK a DN attribútumát: 


ldifde -f hapsi.txt -d "DC-netacademia,DC-net" 
4 -r (en-Hapsi) -1 dn 


A hapsi.txt fájl tartalma ezek után ennyi: 


dn: CN-Hapsi, OUsmarketingesek, DC-netacademia , DCsfm 
changetype: add 


Ezt már csak át kell írnunk olyan módosítássá, ami Hapsit át- 
repíti a kijelölt 0U-ba: 


dn: CN-Hapsi, DC-netacademia, DC-fm 
changetype: moddn 

newrdn: Hapsi 

deleteoldrdn: 1 


newsuperior: ousmarketingesek, dcsznetacademia, dcsfm 


Joggal vetődik fel a kérdés, hogy ezt meg honnan tudom. A 
válasz talán meglepő, de a 2849-es RFC-ből olvastam ki [2] 


Jelszómódosítás LDIF-fel 

Második példám igazán abszurd, ugyanis Hapsi jelszavát fogom 
átállítani LDIF-ből, amihez a puszta szintaxison kívül kell 1-2 
dolog még, mert ezt a mezőt nem hagyja az Active Directory 
csak úgy" babrálni. Sem kiolvasni, sem módosítani nem lehet, 
egyedül a Replace művelet engedélyezett, az is csak SSL-en ke- 
resztül, továbbá High Encryption Package kell hozzá, valamint 
a jelszót base64 kódolással kell beírni a fájlba: 
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dn: CN-Hapsi,DC-netacademia,DC-net 
changetype: modify 

replace: unicodePwd 

unicodePwd: : agshhbGlobw-— 


Az SSL miatt a parancssor is változik: 
Ldifde -i -f akarmi.txt —t 636 


A jelszó átkódolására pedig ezt az agyament, viszont bravú- 
ros módszert találta nekem az MSDEV lista: 

select cast("haliho" as varbinary) as pwd 
4 for xml raw, binary base64 


A cikkben szereplő URL-ek: 


WINDOWS 2000 4 LDAP, LDIF 
A cikkben szereplő példák az [1] címen találhatók meg, 
mégpedig egyetlen, ömlesztett fájlban, ahol a tartomány- 
nevet XXX és YYY karakterekkel helyettesítettem, hogy 
könnyen, gyorsan, egy mozdulattal ki lehessen cserélni a 
saját, otthoni nevekre. Ezután lehet az egyes részeket ki- 
csi fájlocskákba kikopizni, és lefuttatni. 

Utunk végére értünk, remélem szép, ismeretlen tájakat sike- 
rült bemutatnom e kirándulással, legközelebb a WMI sötét si- 
kátoraiba kalauzolom Önöket! 


Fóti Marcell 
marcellf-onetacademia.net 
MCT, MCSE, MCDBA 


Nehéz volt? És mi ez NetAcademia Active Directory 
mélyvíz tanfolyamhoz képest! 
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WINDows 2000 b 


Vizsgáljuk meg kedvenc operációs rendszerünk rendszertöl- 
tés alatt kifejtett aktivitását, melyből igen sok érdekes, a 
Windows belső működését is megvilágító rendszerfolyamat 
működésére derülhet fény. 
Kezdetben úgy gondoltam, hogy most már nem védem a ked- 
ves olvasót a valós hálózatok valós terhelésétől, hisz birto- 
kunkban a szűrők összes változata, ám a webre az [1] címre 
elhelyezett capture fájljaim mégis mindenféle egyidejű háló- 
zati forgalom zavaró hatásának kiszűrésével készültek, egy- 
szerűen azért, hogy a fájl minél kisebb legyen. Hiszen ha 
összegyűjtöttem volna mindazt a hálózati forgalmat, ami egy 
vizsgált Windows 2000 több percnyi rendszertöltése alatt há- 
lózatunkon lezajlott, több megabájtos fájlokat kellett volna 
az [1] címre mentenem. Annak ellenére, hogy már a forgalom 
elkapásakor dolgozott egy szűrő, mely csak a kiszemelt gép 
hálózati forgalmát engedte rögzíteni, a legnagyobb fájl így is 
236 kilobájtos lett - ennyibe ,kerül" egy Windows 2000 Ad- 
vanced Server tagkiszolgáló bebootolása! 
Három fájlunk van ebben a hónapban: 
"0 A w98boot.cap egy Windows 98 rendszertöltésének forgal- 
mát tartalmazza 
"0 A w2kboot.cap a fent említett Windows 2000 Advanced Ser- 
ver tagkiszolgáló bootolásának folyamatát lesi meg 
"A A wakshut.cap ugyanennek a gépnek a leállítását követte 
nyomon. Erre a cikk terjedelmi korlátai miatt nem térek ki, 
házi feladat! 


A Windows 98 bootolása 

Bár a Windows 98 már nem igazán tekinthető friss operációs 
rendszernek (egyesek szerint operációs rendszernek sem), nap- 
jainkban fut még néhány millió a hálózatokon, így nem ha- 
szontalan megvizsgálni, mit is művel. A Windows ME hálózati 
forgalma kísértetiesen hasonló - lenne, ha ezen a gépen fu- 
tott volna az Active Directory ügyfélszoftver és/vagy a gép be- 
jelentkezett volna a tartományba. Az alábbi ábráról tulajdon- 
képpen teljeskörűen leolvasható, hogy mit tesz a masina a há- 
lózaton: ARP-vel keres egy IP címet, NetBIOS regisztrációt vé- 
gez a NETTERM98 és NETACADEMIA nevekre, valamint ICMP 
Router Solicitation üzenetet küld. Ebből a néhány sorból ki is 
derül, hogy a gép nem DHCP ügyfél, hisz IP cím kérő hálózati 
forgalom nem ékelődik be a legelső ARP, és a közvetlenül ez 
után következő NetBIOS névregisztráció közé. 
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(VI. rész) 
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ARP PARP ARP: Reguest, Target IP: 172.16.0.2 


"BROADCAST KBT MS: Registration reg. for METTERN98 005 
"BROADCAST NBT HS: Registration reg. for METACADEHIA 6007 
"BROADCAST NBT NS: Registration reg. for METTERH9O 2037 


USC — 000002 ICHP Router 5014. 








"BROADCAST BT "S: Registr reg. tor NETTERM98 035 
"BROADCAST NET HIS: Regiseri teg. for NETACADEMIA 005 
"BROADCAST NBT HIS: Registration reg. for METTERIM99 2005 
"BROADCAST NET HIS: Registration reg. for METTERI98 005 
"BROADCAST BT HIS: Registration reg. for METACADEMIA 007 
"BROADCAST BT MS: Registration reg. for NETTERH9O 035 
"BROADCAST NET HIS: Registration reg. for NETTERM98 203 
"BROADCAST NBT NS: Registration reg. for NETACADEMIA 4007 
9BROADCAST BET HIS: Registration reg. for NETTERI99 2002 

USC — 000002 ICHP Router Solicítation - 
31 

ÍNET Session protocol summary Fe: 297212 loff: 





a A Windows 98 bootolásának forgalma - részlet 


Érdekes megfigyelni, hogy a legelső ARP mintha céltalan lenne: 
nem várunk a válaszra (hanem azonnal usgyi Broadcastolni) , és 
nem is jön válasz. Mi lehet ez? 

Ez az úgynevezett Gratious ARP, melynek feladata az eset- 
leges IP cím ütközések feltárása. Ebben a csomagban a Win- 
dows 98 a saját, registryből kiolvasott IP címére kérdez rá 
a nagyérdeműtől: 


- Fiúk, kinek az IP címe .. az én IP címem? 


Ha bárki válaszol, akkor az adott IP cím foglalt. Mivel nem jött 
válasz, a gép használatba veszi a címet. Nem időznék ennél 
hosszabban az ARP protokollnál, hisz egy korábbi részben szin- 
te bitszinten kielemeztük, ugorjunk a második csomagra, ahol a 
NETTERM98 NetBIOS név regisztrációja történik. 


NetBIOS 

A NetBIOS interface (és NEM protokoll!) egy viszonylag régi, 
elavulófélben lévő réteg a Windowsok rétegzett hálózati arc- 
hitektúrájában. Elsődleges feladata egy ember által is kön- 
nyen kezelhető névtér hozzárendelése az egyes gépekhez, 
hogy a kedves felhasználóknak például ne IP cím alapján kell- 
jen távoli meghajtókra csatlakozniuk (bár IP címmel is lehet. Try: 
1112.34.56.781share !) Tisztán Windows 2000-es hálózatban 
nincs is rá szükség, de egyelőre viszonylag kevés ilyen hálózat- 
ról tudunk sajnos. A NetBIOS halála azért elkerülhetetlen, mert 
— ellentétben a DNS-sel - névtere kétdimenziós, azaz hierarchiá- 
ba nem lehet felfűzni a gépeket. 

A NetBIOS nevek 16 bájtosak, ebből 15 bájt van fenntartva a 
gép/tartomány/ szolgáltatás nevének, a 16. bájt pedig az adott 
névhez tartozó szolgáltatás kódja. A fenti ábrán látható névre- 
gisztrációs utasításokon megfigyelhető a név, és a névhez tar- 
tozó szolgáltatáskód is, például: 


NETACADEMIA 2005 


tech.net! 


WINDOws 2000 


A teljesség igénye nélkül felsorolom a leggyakoribb szolgálta- 
táskódokat, melyekről a Microsoft Knowledge Base-ben olvas- 
hatunk bővebben: 


00 — Workstation Service (ez a gép képes fájl- és nyomtatószol- 
gáltatás igénybevételére) 

03 — Messenger Service (az adott névre üzenetet lehet küldeni 
Net Send paranccsal, vagy Winpopuppal) 

20 Server Service (ez a gép képes fájl- és nyomtatószolgálta- 
tás nyújtására. A 20-as rekord az alapértelmezett, ez nem 
írja ki külön a NetMon, lásd fenn.) 

1B — Domain Master Browser 

1C — Domain Controller 

BE — Network Monitor AGent 








Egy elinduló gép sorban bejegyzi a WINS Serverbe (vagy, mint 
a fenti ábrán, WINS hiányában Broadcasttal adja a többi gép 
tudtára), hogy milyen szolgáltatásokat érdemes nála keresni. 

(Egy WINS adatbázis elég sok mindent elárul egy botcsinálta ha- 

ckernek. A fenti rekordokon kívül ugyanis van még egy-kettő: az 

IIS is bejegyzi magát, az SOL Server sem tagadja le, hogy fent 

van egy adott gépen stb.) 

NetBIOS névfeloldásnak nevezzük azt a folyamatot, amikor a 

munkaállomás a felhasználó által megadott gépnévhez meg- 

próbálja megkeresni a célgép IP címét, és a kért szolgáltatást. 

Ennek a folyamatnak sokféle változata képzelhető el, de min- 

dig két alapeset kombinációjával állunk szemben: vagy broad- 

castot használunk, vagy NetBIOS Name Servert (WINS). E ket- 
tő módszer mellett létezik persze nem hálózatos névfeloldás is 
az LMHOST fájl képében, de ez a NetMon szempontjából közöm- 
bös, mivel nem látszik a hálón, s így el sem tudjuk kapni. Az 
előző kettőt azonban igen! Mi több, meglepetéssel tapasztal- 
hatjuk, hogy e kettő vegyesen szerepel a legtöbb hálózaton. 

Ennek az az oka, hogy a munkaállomás az úgynevezett Node 

Type beállítás függvényében képes egyszerre akár mindkét 

módszert használni. A következő Node Type állapotok léteznek: 

"0 B Node: Broadcast üzemmód. Ekkor a munkaállomás ki- 
zárólag broadcast alapú névfeloldással próbálkozik, s ha ez 
nem sikerül, hibaüzenetet kapunk. Ez a típus használhatat- 
lan több szegmensből álló, útválasztóval összekapcsolt háló- 
zatok között, mivel minden jól nevelt router elnyeli a broad- 
castokat, így ezzel a módszerrel a túlsó hálózat gépei név sze- 
rint nem érhetők el. De hangsúlyoznám, hogy IP címmel igen! 

0 P Node: Peer üzemmód. Ebben az esetben a munkaállomás 
csak WINS lekérdezést használ, ami ugyan tetszőleges tá- 
volságban lévő WINS ügyfél megtalálására alkalmas - de a 
tőlem másfél méterre lévő gép mégsem lesz név szerint 
használható, ha az valamilyen okból nem WINS kliens, és 
nem regisztrálja be nevét a WINS kiszolgálóba. 

1 M Node: Mixed üzemmód. Az előző két módszer előnyeit 
egyesíti. A munkaállomás először broadcast-tal próbálkozik, 
majd ha az nem jött össze, a WINS-hez fordul. Tekintettel 
arra, hogy egy tipikus vállalati hálózatban majdnem minden 
gép WINS kliens, ez a stratégia sávszélességpazarló lehet. 

"0 H Node: Hybrid üzemmód. Ilyenkor a munkaállomás először 
a WINS kiszolgálót kérdezi, majd ha negatív válasz érkezik, 
bánatában broadcast-ol egyet - hátha sikerül. Saját tapaszta- 
latból mondom, hogy a Hybrid igen hasznos üzemmód, mert 
ha egy célgép nem WINS ügyfél, a broadcast még mindig 
elérhetővé teszi név szerint - legalábbis azonos alhálón. 
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MICROSOFT NETWORK MONITOR (VI. 


RÉSZ) RENDSZERINDITÁS 
Sajnos fantasztikus eszközünkkel, a Network Monitorral csak 
következtetni tudunk gépeink Node Type beállítására, a biztos 
módszer ugyanis a parancssorban lakozik: az IPCONFIG /ALL 
parancs szépen kiírja a képernyőre a Node Type beállítást. 
(Win98 esetén WINIPCFG) 

Akármilyen úton-módon szerezte is meg gépünk a névhez 
tartozó IP címet, a választ egy helyen tárolja: a NetBIOS Ca- 
che-ben. Könnyedén meggyőződhetünk ennek tartalmáról az 
NBTSTAT -c paranccsal. Az így megjelenő listában nemcsak 
neveket, hanem szolgáltatáskódokat is találunk, a c0x20- 
például azt jelenti, hogy a feloldott nevű gépen van fájl-és 
nyomtatószolgáltatás, azaz fut a Server service. 

Távoli gépek NetBIOS cache-e is kilistázható, egyszerű mód- 
szert adva a kétbalkezes hacker kezébe, hogy megállapíthassa: 
vajon egy távoli gépen ki van bejelentkezve? 

Az [1] címről letölthető w98boot.cap fájl 23. csomagjában meg- 
figyelhetünk egy NetBIOS névkérésre érkező választ, melynek 
kérdésrésze valahova elveszett, eltűnt a Network Monitor árgus 
tekintete elől, ami nem jó jel. Úgy látszik, ez is csak szoftver... 
A 29. csomagban NETTERM98 NetBIOS Session építési kérelmet 
küld PLATAN-nak, mégpedig a feladó Workstation -00- szolgál- 
tatása a címzett Server szolgáltatására c202. Erre egyszerre, 
egy időben két válasz érkezik (30. és 31. csomag) , mintha PLA- 
TAN dadogna, amit megint csak nem értek - ez is csak szoft- 
ver... Vagy a kannásbor miatt? 

De térjünk vissza a második csomaghoz, nyissuk ki a NetBIOS 
névregisztrációt, s keressük meg benne a regisztrált gépnevet 
(NETTERM98) . Nem fogjuk megtalálni! Helyette ez , olvasható": 


EOEFFEFEEFFCENDJDICACACACACA 


Microsoft Network Monitor - (Uptatantworkicikíett ST 


ee SE Éee 


25.783733  NETTERM98 
25.783733 NETTERM98 


"BROADCAST — NBT 
"BROADCAST — NBT 


PF FF 00 89 00 
00 00 00 00 01 


00 01 00 04 93 BO 00 06 00 00 AC 10 00 02 








[dompressed name representation of Fe: 2/212 


NS: Registration 


us: mesteeretáen 8] 
rímél 





5 A NETTERM98 név hexadecimálisan... 


Ez nem egészen az ugye? Valami titkosítás, vagy átok ül rajta? 

Nem titkosítás, hanem átok. Úgy van lekódolva a név, hogy 

minden betűt két bájt tárol, de nem UNICODE, hanem BCD-jel- 

legű, és még csak az sem. UUENCODE? Nem hinném! Az izga- 

lom kedvéért fejtsük meg gyorsan a kódolást: 

B Az O jellel mutatott szám a string hosszbájtja (0x20-16 
bájt hosszú minden NetBIOS név) 

"2 Akkövetkező két bájt (0x45, 0x4F) lenne az ,N" betű a NET- 

TERM98 névből O 

az ,N" kódja az ASCII kódtáblában 78-Ox4E. 

Ezt a 8 bitet vágjuk ketté, 4-4 bitre (0x4 és 0xE) 

Adjunk mindkettőhöz 0x41-et (Az ABC , A" betűje), s voilá, 

előáll a 0x45, Ox4F 


HÓD 
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A És így tovább a többi karakterre. Ebből látszik, hogy a név 
és a legutolsó szolgáltatásbájt között az üres hely szókö- 
zökkel van feltöltve (0x43, 0x41-20x20-2space). 

Hogy miért PONT így kódolják a neveket, tőlem akár ne is kér- 

dezzék, fogalmam sincs! Ipartörténeti érdekesség. 


ICMP Router Solicitation 

A routerkeresésben talán a címzésmód érdemel kiemelt figyel- 
met. A címzett MAC Addresse (01005E000002) nem broad- 
cast. Vajon kitől kéri le a Windows 98 a Default Gateway cí- 
mét? Lássuk a cél IP címet: 224.0.0.2. Jesszus! Csak nem 
Amerikában keresi a routert? Nem-nem. Ez egy D osztályú Mul- 
ticast cím, amely a Unicast és a Broadcast között helyezkedik 
el félúton: nem is egyetlenegy gépnek szól, de nem is mind- 
nek, hanem csak azoknak, akik ugyanezzel a Multicast címmel 
rendelkeznek. A 224.0.0.2 cím a Multicast szabvány szerint: 
AlLIP Routers. Vagyis a gép bekiabál eme közismert Multicast 
címre, egy olyan csoportnak szólva, melynek tagja az összes, 
e szabványt ismerő útválasztó. Vagyis a Windows 98 MEGTA- 
NULJA, hol a Default Gateway! 

A sok-sok NetBIOS regisztráció és routerfelfedezés után a Win- 
dows 98 rákapcsolódik a tartományvezérlő egyik könyvtárára. 
Minket a könyvtár neve és tartalma annyira nem is érdekel, az 
autentikáció sem fér e cikk kereteibe, így hát a fájl- és nyom- 
tatószolgáltatás protokolljával, az SMB-vel ismerkedünk meg. 


Server Message Block 
A Windowsos fájlátvitel viszonylag magasszintű hálózati mű- 
velet, melynek során rendkívül sok finom részletet beszél meg 
egymással a munkaállomás és a kiszolgáló. A két gép között 
kiépülő TCP csatorna fölött NetBIOS réteg feszül, s e felett 
dolgozik a fájl- és nyomtatószolgáltatások alapvető proto- 
kollja, az SMB (Server Message Block). Az SMB egyelőre nincs 
rajta a Microsoft halállistáján (a MAPI, a NetBIOS és sok 
egyéb egyedi technológia mellé pedig odakívánkozna), de 
előbb-utóbb meghal. Inkább utóbb: a Whistler is SMB alapú. 
Amíg a WebDAV nem lesz képes ellátni az SMB által nyújtott 
összes szolgáltatást, az SMB marad. 
A kapcsolatfelvétel során a részletek ,megbeszélését" Ne- 
gotiationnak, egyeztetésnek hívjuk. Többfajta egyezkedés 
zajlik a két gép között: 
"0 Milyen authentikációs protokollban állapodjanak meg? A 
csoportos házirend függvényében ez a Clear Texttől (hogy 
őslény Lan Manager 0.0 kiszolgálókkal is együtt tudjunk mű- 
ködni) NTLM-en át (hajrá LOPHTCrack!) a Kerberosig terjed- 
het. Ezekkel most nem foglalkozunk. 
Melyik verziójú SMB-t beszéli a két fél? Ennek , letárgyalá- 
sa" azért fontos, hogy kiderüljön, hogyan kell felépíteni az 
átküldött parancsot, s milyen információkat támogat a két 
fél a fájlok tartalmával, valamint a fájlnevekkel kapcsolat- 
ban? Csak a 8.3-as nevek mehetnek? Vagy hosszú fájlnevek 
is? Esetleg Unicode? 

"I NTFS spécik: Az NTFS-en a fájlok egyedi attribútumokkal 
rendelkezhetnek. Át lehet-e virini ezeket? A tömörített fáj- 
lok tömörítve kerüljenek a hálóra, vagy ki kell előbb bon- 
tani, mert a túloldal nem ismeri a tömörítési algoritmust? 
És az EFS-sel titkosított fájlok vajon titkosítva menjenek-e 
át a hálón? Nyilván igen. Vagy mégse...? 


b 
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Az egyezkedés gyönyörűen látszik a NetMonnal, a 32. csomag- 
ban a kapcsolatfelvételt kezdeményező NETTERM98 felsorolja, 
hogy az SMB mely dialektusait, , tájszólásait" beszéli. Az alábbi 
ábra arról tanúskodik, hogy eszméletlen régi SMB változatok is 
a palettán vannak. Ez teszi lehetővé, hogy olyan ócskaságokkal 
is szóba álljon, mint egy Lan Manager 0.0. A lista elemei felül- 
ről lefelé egye , erősebbek", tehát a Windows 98 által , beszélt" 
legújabb SMB az NT LM 0.12. 
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a A Windows 98 által ismert SMB változatok 


Az alábbi ábrán a w2kboot.cap fájl 510. csomagja látható, ahol 
egy Windows 2000 Advanced Server kezdeményez fájlátvitelt, 
ennek érdekében felsorolja az általa ismert SMB változatokat: 
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5 A Windows 2000 Advanced Server által ismert SMB válto- 
zatok 


Mint azt láthatjuk, a legfejlettebb SMB dialektus itt is az NT LM 
0.12, ugyanaz, mint a Windows 98 esetében! A 33. csomagban 
a dialektuslistából egyébként PLATAN a legerősebbet, az ötödi- 
ket választja (a sorszámozás nullától indul). 

Emellett különböző flagbitek szolgálnak az operációs rendszer 
tudásszintjének pontosabb betájolására. A Windows 98 ezt tud- 
ja (gyakorlatilag semmi különöset, mindenütt nulla áll): 


SMB: Flags Summary - 128 (0x80) 
dszőesé 0 z Lock § Read and Write § Unlock not 
4 supported 
..0. 5 Send No Ack not supported 
....0... 5 Using case sensitive pathnames 
...0.... z No canonicalized pathnames 
sllisnó z No Opportunistic lock 
dössssés z No Change Notify 
SMB: flags2 Summary - 0 (0x0) 


ség Ssedüseéztkd 0 - Understands only 


WINDOWS 2000 


4 Dos 8.3 filenames 
KAZE s eölététa gel 0. z- Does not understand 

4 extended attributes 
sájdlls srérátsigíszéjvtsáns z No DFS namespace 
eds zezáésszstds z No paging of IO 
Jag áss s ssálgagőe z Using SMB status codes 
LETE ás gzEsES - Using ASCII strings 


A nyomozás jelenlegi állása szerint nem tudnám megmondani, 
hogy a Windows 98 miért tagadta le a hosszú fájlneveket. . . 

Talán nem lenne minden tanulság nélküli a Windows 98 fenti 
bitgyűjteményének összevetése a Windows 2000 hasonló listá- 
jával. Íme a különbségek (ahol egyes állt a Windows 2000-nél): 


SMB: Flags Summary - 24 (0x18) 


Using caseless pathnames 


Canonicalized pathnames 





SMB: flags2 Summary - 51283 (0xC853) 
ess séseséée.. 1 - Understands long filenames 
vesse... 1. - Understands extended attributes 





dás és épááló z Using NT status codes 
Ülsz azás üásdtlsű z Using UNICODE strings 


Case-insensitive fájlnevek (kis- és nagybetű különbözik) és Ex- 
tended NTFS attribútumok kezelése. Ennyi a különbség, se 
több, se kevesebb. Ebből az következik, hogy: 


Az SMB protokoll mind a mai napig nem támogatja az NTFS 
speciális fájltárolását (az attribútumokat igen!). 

1. Az NTFS tömörített fájljai kitömörítve utaznak a hálón még 
akkor is, ha mindkét fél Windows NT/2000. 

2. Az EFS-sel titkosított fájlok kibontva, titkosítás nélkül utaz- 
nak a hálón, mivel az SMB nem tudja lekezelni a titkosítást. 


Természetesen állításaim igazságáról bárki meggyőződhet saját 
hálózatán néhány spéci NTFS fájl lemásolásával. Ezzel megta- 
láltuk az okát annak, miért ,árja elő" a marketingbrosúra IPSec 
alkalmazását még EFS-sel titkosított fájlok esetén is. Ugye 


megmondtam, hogy a NetMon mindenre jó? 


Browse Service 

Külön hálózati , szolgáltatás" (már ha lehet szolgáltatásnak ne- 
vezni) a Browse Service, mely még manapság is alapvető fon- 
tosságú a hálózati erőforrások megtalálásában (Network Neigh- 
borhood), annak ellenére, hogy számtalanszor bizonyította, 
nagy hálózatokon képtelen normálisan üzemelni. Hol kikap- 
csolt gépek virítanak a listájában, hol bekapcsolt gépek megje- 
lenésére várunk - hiába. Ennek a megbízhatatlan működésnek 
az egyik alapvető oka, hogy amikor tallózunk, sohasem friss 
adatokat látunk (akárhogy csapkod is a zseblámpa, NEM azon 
ügyködik, hogy körbekérdezze a létező gépeket), hanem az úgy- 
nevezett Master Browser majdnem friss, illetve nagyobb há- 
lózatok esetén a Backup Browserek garantáltan elavult erőfor- 
ráslistájában kattintgathatunk önfeledten. A másik oka a Brow- 
ser által használt kapcsolatmentes UDP szolgáltatás, mely 
olyannyira nem garantálja a lentebb felsorolt csomagok célba- 
juttatását, hogy még az RFC is említ olyan eseteket, amikor az 
UDP befuccsol. Például ha a célgép MAC Addresse nincs benn a 
feladó ARP cachében, akkor az UDP elkiabál a levegőbe. (Itt 
jegyzem meg, hogy igazi rendszergazda nem vacakol a Browse 


tech.net! 


MICROSOFT NETWORK MONITOR (VI. 





RÉSZ) RENDSZERINDITÁS 
szolgáltatással, hanem egyszerűen megkerüli: ha UNC útvonalak- 
kal (masina printer], bemeppelt meghajtóval, vagy parancsiko- 
non kattintva dolgozunk a hálón, és nem érintjük a Network Neig- 
borhood ikont, elsiklunk a Browse mellett...) A Browse szolgálta- 
tás hálózati forgalmának valamelyes megértése sajnos még nap- 
jainkban is szükséges. Milyen csomagokkal találkozhatunk? 

-£ Host Announcement: minden számítógép időről időre köz- 
lia Master Browserrel, hogy még mindig életben van. 
Emellett meglepő részletességgel közli az általa futtatott 
szolgáltatások listáját is. Pont, mint a WINS. A két szolgál- 
tatás mégis különbözik, és nem is cserél adatot egymással. 

8 Browser Election: ezt a vicces csomagtípust most sajnos 
nem sikerült elcsípnem. A lényeg az, hogy minden alhá- 
lózaton, azon belül minden protokollon, azon belül 
minden frame type csoportban saját Master Browsernek 
kell lennie. Ez tipikusan a legerősebb gép (nem hardver- 
szempontból, hanem a futtatott operációs rendszer sze- 
rint mérjük az erősséget) , de ha az ki van kapcsolva, ak- 
kor egy másik. Az erősebb gépek induláskor választást 
írnak ki, hogy ki legyen a Master Browser, és a válasz- 
tást azonnyomban meg is nyerik, hisz ők a legerőseb- 
bek. Tiszta politika :) 

"0 Browser lekérdezések: a Network Neighborhood kattogtatá- 
sa váltja ki ezt a műveletet. 

Az alábbi táblázatban egy Announcement csomag azon részle- 

tét láthatjuk, mely a bejelentett szolgáltatásokat sorolja fel 

(w2kboot.cap fájl 369.csomag): 

5 Egy Browser Announcement bitjei 
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Pestiesen szólva: nem semmi. Hackerként megtudhatjuk pél- 
dául - ha eddiga NetBIOS cache-ből nem listáztuk ki - hogy 
a gépen nemcsak a Workstation és a Server service fut, ha- 
nem van rajta egy SOL Server is. Külön érdekesség, hogy ez 
a kutyát sem érdekli. (Helyesbítek: az SOL Server Enterprise 
Managere ez alapján listázza ki a felvehető SOL Servereket. ) 
Viszont az is feketén-fehéren kiderül, hogy ez a Windows 
2000 nem Novell Netware, nincs rajta Time Service (de van, 
csak nem master) , Browse szerepe pedig Backup Browser. És 
nem Windows for Workgroups. Hanem NT.:-O 


Fóti Marcell 
marcellfronetacademia.net 
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Amikor nagyméretű hálózatokkal dolgozunk, különösen fon- 
tos, hogy a felhasználók és számítógépek beállításait köz- 
pontilag tudjuk kezelni. E feladatra a Windows NT 4.0 ope- 
rációs rendszer esetében a System Policy áll rendelkezé- 
sünkre. Az eszköz nagyon jól használható a regisztrációs 
adatbázis azon beállításainak megváltoztatására, amelyek 
számítógépre (HKEY LOCAL MACHINE hive - HKLM), illetve a 
felhasználóra (HKEY CURRENT USER hive - HKCU) vonatkoz- 
nak. Az imént említett hive-ok alatt bármely bejegyzést 
felül tudunk írni, ha a regisztrációs adatbázis kulcsain beál- 
lított jogosultság ezt lehetővé teszi. De óvatosan kell eljár- 
nunk, mert balszerencsés esetben - és az előzetes gondos 
tesztelés elmulasztásával - komoly fennakadások idézhetők 
elő a számítástechnikai rendszer működésében. 

A System Policy révén a felhasználói felületen számos kor- 
látozást tudunk érvényre juttatni. Ezek a tiltások azonban 
csak elrejtenek bizonyos funkciókat a felhasználók elől, 
nem tekinthetők valós biztonsági beállításoknak. Jó példa 
erre a házirenden keresztül megvalósítható korlátozás, 
amely megakadályozza a Registry Editor elindítását. Ez 
azonban nem jelent elegendő védelmet, hiszen a tiltás el- 
lenére a regisztrációs adatbázis könnyen módosítható a 
megfelelő fájl (.reg) lefuttatásával. A System Policyval fő- 
ként olyan korlátozások valósíthatók meg a leghatékonyab- 
ban, amelyekkel lényegesen csökkenthetjük a felhasználói 
hibákból fakadó működési zavarok kockázatát. 

Ezzel szemben a Windows 2000 operációs rendszerben lévő 
csoportos házirend (Group Policy) segítségével a rendszer- 
gazdai feladatok sokkal szélesebb körét tudjuk központilag el- 
látni. A csoportos házirend esetében ugyanis a regisztrációs 
adatbázis bejegyzéseinek megváltoztatása csak egy funkció a 
sok közül. Ezen kívül már valós biztonsági beállításokat is 
megvalósíthatunk. Hiszen nem csak a fájlrendszerre, de a re- 
gisztrációs adatbázisra vonatkozó jogusoltságot is kiosztha- 
tunk. Mindezek mellett logon/logoff, startup/shutdown scrip- 
teket is kezelhetünk, sőt programtelepítésre is lehetőségünk 
van. A csoportos házirend - a System Policyhoz hasonlóan - 
ugyan lehetőséget ad arra, hogy a HKLM és a HKCU hive-ok 
alatt bárhol módosítsuk a bejegyzéseket, de alapértelmezés- 
ben nem támogatja ezt. A Windows 2000 regisztrációs adatbá- 
zisában előre meghatározott helyeken találhatóak a házirend- 
del kapcsolatos bejegyzések. Mind a felhasználóra, mind a szá- 
mítógépre vonatkozó beállítások a megfelelő hive-hoz tartozó 
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kulcsok alatt jelennek meg. 
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A csoportos házirend működése 

A csoportos házirendet csak tiszta Windows 2000-es környe- 
zetben használhatjuk. A Group Policy ugyanis szorosan kötő- 
dik az Active Directoryhoz (AD). A házirendbeállítások az AD 
felépítésének megfelelően objektumokban tárolódnak (Group 
Policy Object - GPO) , amelyeket az AD fő egységeihez (telep- 
hely, tartomány, szervezeti egység) tudunk hozzárendelni. 
Házirendobjektumot a Group Policy snap-in segítségével hoz- 
hatunk létre, amelyet önálló eszközként is használhatunk, de 
elérhetjük az Active Directory Users and Computers, valamint 
az Active Directory Site and Services kiterjesztéseként is. Ez 
utóbbi megoldás sokkal kényelmesebb, hiszen a GPO-kat, 
mint az imént már volt róla szó, valamelyik AD egységhez kell 
hozzárendelnünk. Természetesen az Active Directory Sites and 
Services használatakor csak telephelyhez tudunk GPO-t kap- 
csolni. Ha tartomány vagy szervezeti egység szintjén akarunk 
házirendet érvényesíteni, akkor az Active Directory Users and 
Computerst kell igénybe vennünk. Abban az esetben például, 
ha egy szervezeti egységhez szeretnénk kapcsolni egy házi- 
rendobjektumot, akkor a szervezeti egység tulajdonságait 
megjelenítő párbeszédablakban (Action menü Properties pa- 
rancs) válasszuk ki a Group Policy fület. 
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5 GPO létrehozása, törlése, prioritása, láncolása, örök- 
lődés beállítása -— minden egy helyen! 


A képen látható felületen tudunk új GPO-t létrehozni az adott 
szervezeti egységen (New nyomógomb). Ezen túlmenően már 
létező GPO-kat is hozzákapcsolhatunk (Add nyomógomb). 
Természetesen lehetőségünk van a házirendobjektumok beál- 
lításainak módosítására is (Edit nyomógomb) . Vegyük figye- 
lembe, hogy ha egy GPO-t több szervezeti egységhez is hoz- 
zákapcsolunk, akkor bármelyik helyen módosítjuk is a beállí- 
tásokat, a változások minden olyan szervezeti egységnél érez- 
tetni fogják a hatásukat, amelyhez a házirendobjektumot tár- 
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sítottuk. Ha több objektumot rendeltünk valamelyik szerve- 
zeti egységhez, akkor az Up és a Down gombbal tudjuk a sor- 
rendjüket meghatározni. Ennek abban az esetben van jelen- 
tősége, ha a GPO-k egymást átfedő beállításokkal is rendel- 
keznek. Ilyen esetben a sorrendben előrébb lévő objektum 
beállításai érvényesülnek. 

Az Options gomb megnyomásakor feltűnő ablakban egyrészt 
letilthatjuk a házirendobjektumot az adott tárolón (Disabled 
jelölőnégyzet) , másrészt megakadályozhatjuk a házirend fe- 
lülbírálását (No Override jelölőnégyzet). Ez utóbbi esetben 
az alsóbb szintű tárolókon érvényes házirend nem írja felül 
a szóban forgó GPO beállításait. Például ha tartományi szin- 
ten érvényes GPO-nál engedélyezzük a No Override jelölő- 
négyzetet, akkor az objektum által képviselt házirend az 
egész tartományban érvényes lesz, függetlenül attól, hogy a 
szervezeti egységeknél mit állítottunk be. Így lényegében az 
alapértelmezett öröklődési szabályokat változtatjuk meg. 
Ezen túlmenően módunk van arra is, hogy az öröklődést az 
AD-hierarchia bármely szintjén letiltsuk. Ezt az Options 
gomb alatt található Block Inheritance jelölőnégyzettel tud- 
juk megvalósítani. Érdemes azonban óvatosan bánni az 
öröklődési szabályok megváltoztatásának lehetőségével, 
mert nagyon megnehezítheti a hibaelhárítást. 

Korábban már esett róla szó: egy GPO-t több tárolóhoz is hoz- 
zákapcsolhatunk. A házirend szerkesztésekor azonban nagyon 
fontos tudnunk, hogy a változtatások mely területeken érez- 
tetik majd hatásukat. Szerencsére erről nem kell külön nyil- 
vántartást vezetnünk, hiszen a házirendobjektum tulajdonsá- 
gait megjelenítő párbeszédablakon (Properties nyomógomb) 
hozzáférhetők ezek az információk. A Links fülön található 
Find Now gombbal ugyanis megkereshetők azok az AD táro- 
lók, amelyek a szóban forgó házirendobjektumot használják. 
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General Links ] Security ] 






212 


Search for Sites, Domains and OU" that use this Group Pobcy 
3 Object. Click the Find Now button to start the search. This might 
take several minutes to complete. 


Donén fm ZETI 
Sítes, Domains or Organizational Units found: 


Hypo.huz 


Hypo.hu/Domain Conttrollers 
Hypo.hu/GPTST 
Hypo.hu/User accounts 





OK Cancel hoply 


a Egy GPO egyidejűleg sok helyen felhasználható 








A Links mellett a Security fülről is érdemes szót ejteni. Itt 
lehet a GPO-hoz hozzáférési jogosultságot beállítani. A jogo- 
sultsági listában Apply Group Policy néven egy speciális jo- 
gosultság is fellelhető, amellyel az Authenticated Users cso- 
port révén alapértelmezésben minden felhasználó rendelke- 
zik. Ezzel a joggal szabályozhatjuk, hogy a beállítások mely 
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felhasználókra, illetve felhasználói csoportokra legyenek 
érvényesek. Bár a szervezeti egység a legkisebb olyan ob- 
jektum, amelyhez GPO-t rendelhetünk, a jogosultsági listán 
keresztül a csoportok szintjén is szabályozhatjuk a házi- 
rend végrehajtását. Ennek a megoldásnak előnye és hátrá- 
nya is van. Előnye: sokkal differenciáltabban lehet megha- 
tározni, hogy mely felhasználókra vonatkozzék az aktuális 
házirend. Hátránya: nagyon megnehezíti annak megállapí- 
tását, hogy melyik beállítás miért, vagy éppen miért nem 
jelenik meg az egyes felhasználóknál. Ha valamelyik cso- 
porttól elvonjuk az Apply Group Policy jogot, akkor érde- 
mes a Read jogot is letiltani, elsősorban a teljesítményt 
növelendő. Ellenkező esetben az operációs rendszer sorra 
veszi a GPO beállításait, bár nem érvényesíti őket. 
Előfordulhat, hogy egy házirendobjektum csak felhasználóra 
vagy csak számítógépre vonatkozó beállításokat tartalmaz. 
Ilyenkor érdemes letiltani a házirend nem használt részét, 
mivel ezzel is csökkenthetjük a végrehajtás idejét. A letiltást 
a General fül Disable Computer Configuration settings, illet- 
ve Disable User Configuration settings elnevezésű jelölő- 
négyzettel tudjuk végrehajtani. 


A Group Policy objektumokkal kapcsolatos információk 
tárolása 

A csoportos házirendre vonatkozó információk tárolására a 
Group Policy Container és a Group Policy Template szolgál. Az 
előbbi az AD azon tárolója, amely a házirendobjektumok tulaj- 
donságait (verziószám, státusz stb.) tartalmazza. Az utóbbi 
a fájlrendszerén lévő könyvtárstruktúrának az elnevezése, 
amelyben az Administrative Template-en alapuló házirend- 
beállítások, script fájlok (logon/logoff, startup/shutdown) 
stb. találhatók. A Group Policy Template mappaneve minden 
esetben megegyezik a GPO egyedi azonosítójával (GUID) , és 


$SYSTEMROOT$iSysvollcSYSVOL MEGOSZTASZ(cTartomány- 
névoXPoliciesN 


elérési út alatt található a tartományvezérlőkön. A Sysvol 

megosztás tartalma a File Replication Service jóvoltából au- 

tomatikusan replikálódik, így a módosítások mindegyik tar- 
tományvezérlőhöz eljutnak. (A GPO-k tartományok között 
nem replikálódnak. ) 

A Group Policy Template az alábbi alkönyvtárakat tartal- 

mazhatja: 

8 Adm: A házirendobjektum beállításaihoz szükséges sab- 
lonfájlok (.adm) helye. 

8 Machine: Ebben a mappában a Registry.pol fájl találha- 
tó. Az állomány a regisztrációs adatbázis HKLM hive 
alatt lévő bejegyzéseit tartalmazza, amelyeket a házi- 
renden keresztül módosítottunk (Computer Configurati- 
on! Administrative Templates) . 

"8  MachineW4pplications: Tartalma attól függően változik, 
hogy mely alkalmazások telepítését. rendeltük hozzá a 
számítógépekhez a csoportos házirend segítségével. 

"8 MachineWicrosoftiWindowsNTNSecedit: Az itt fellelhető 
GptTmpL.inf fájl a tartományvezérlőn érvényes biztonsá- 
gi beállításokat tartalmazza. Abban az esetben, ha a tar- 
tományvezérlőhöz kapcsolt GPO 
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Computer ConfigurationlWindows Settingsl 


0 Security Settings 


beállításait módosítjuk, akkor GptTmpl.inf tartalma is 
módosul. 

"8 MachineMScriptsiShutdown: A számítógép leállításakor 
elinduló scriptek mappája. 

"8 MachinetScriptsAStartup: A számítógép elindulásakor le 
futó scripteket kell ebben a könyvtárban elhelyeznünk. 

0 User: Ebben a mappában a Registry.pol fájl lelhető fel, 
amely a regisztrációs adatbázis HKCU hive alatt lévő, a 
házirenden keresztül módosított bejegyzéseit tartalmazza 
(User Configuration ) Administrative Templates) . 

"0 Uservapplications: A felhasználók számára meghirdetett 
programtelepítés esetén ebben a könyvtárban létrejön 
egy -aas kiterjesztésű állomány, amelyet a Windows In- 
staller használ. 

"8 UserWocuments 8. Settings: A speciális mappák (My 

Documents, My Pictures stb.) átirányításával kapcsolatos 

információkat hordozó Fdeploy.ini elnevezésű fájl kerül 

ebbe a mappába. 

UserWMicrosoft EAK: A GPO 


A 


User ConfigurationlWindows SettingsY 


(0 Internet Explorer Maintenance 


beállításaival kapcsolatos információk lelőhelye. 

8 UserMScriptstLogoff: A felhasználó kijelentkezésekor lefu- 
tó scripteket tárolja. 

"0 UserMScriptstLogon: A felhasználó bejelentkezésekor lefu- 
tó scriptek mappája. 

"8 UserWicrosoftiRemotelnstall: A Windows 2000 szerver 
lehetőséget biztosít a rendszergazdák számára, hogy tá- 
voli gépekre Windows 2000 operációs rendszert telepítse- 
nek a Remote Installation Services révén. Ezzel kapcso- 
latos beállításokat a Remotelnstall mappában levő 
OSCfilter.ini fájl tárolja. 

A Group Policy Template mappában a gpt.ini nevű fájl is meg- 
található. Ebben az állományban tárolódik a GPO verziószáma 
a következő formában: Versionscverziószáms. Egy nyolc 
számjegyes DWORD értékről van szó. Az első négy számjegy a 
felhasználóval, az utolsó négy a számítógéppel kapcsolatos 
beállítások verziószámát jelenti. Például a 0XO0080006 arra 
utal, hogy a GPO User Settings részében nyolc, a Computer 
Settingsben pedig hat módosítás történt. Ez a szám decimá- 
lis formában tárolódik. Ha az iménti példát vesszük alapul, 
akkor a gpt.ini fájlban a következőképpen jelenik meg a ver- 
ziószám: Version-05240294. Ennek alapján az esetek többsé- 
gében megállapítható, hogy melyik tartományvezérlőn leg- 
frissebb a házirend. Előfordulhat azonban, hogy két tarto- 
mányvezérlőn egyidőben ugyanazt a GPO-t módosítják a rend- 
szergazdák. Ilyen esetben a replikáció során az egyik módosí- 
tás felülíródik. 


A replikációs konfliktusok előfordulási valószínűségé- 
nek csökkentése végett a Group Policy snap-in -— füg- 
getlenül attól, hogy melyik számítógépről indítjuk el — 
a PDC emulátorral lép kapcsolatba. 
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Így a házirendobjektumokat mindig ugyanazon a tartomány- 
vezérlőn szerkeszthetjük. Ez a működési mód a Group Policy 
snap-in View menü DC Options parancsával megváltoztatható. 
(Ez az utasítás csak akkor áll rendelkezésünkre, ha a Group 
Policy snap-in felhasználói felületének bal oldalán megjelenő 
fa gyökerét jelöljük ki.) 







§ Group Policy 







Ell Computer Configuration 


Large Icons 
el user Configuration 


Small Icons 








s CI Administrative Templates 


Options for domain controller selection Ké 2] 


"When Group Pobcy is selecting a domain controller, it wil use the option 
hé chosen below. There is a pobcy that may ovenide this preference. This wil 

take elfect the next me this snap-n is started. 

6 [fhe one wihthe Öperalions Master token for the PDC emulatol 

C The one used by the Active Directory Snap-áns 

C Use any available domain controller 


Le]  . crea] 


opi 





a Melyik házirendpéldányt szeretnénk szerkeszteni? 


Ha a DC Options parancsra klikkelünk, az Options for domain 
controller selection elnevezésű párbeszédablak jelenik meg, 
amelyen háromféle választási lehetőségünk van: 

"8 The one with the Operations Master token for the PDC 
emulator: Ez az alapértelmezett beállítás. Számottevő 
előnye, hogy elkerülhetők a replikációs konfliktusból 
eredő problémák, hiszen a házirendobjektumokat min- 
dig ugyanazon a tartományvezérlőn tudjuk szerkesz- 
teni. Ebből következően ez az ajánlott beállítás, 
amelytől csak speciális esetben érdemes eltérni. Pél- 
dául akkor, ha a lassú hálózati kapcsolat miatt a PDC 
emulátor nehezen érhető el. 

"8 The one used by the Active Directory Snap-ins: Azon a 
tartományvezérlőn fogjuk a GPO-kat szerkeszteni, ame- 
lyikkel az éppen használt Active Directory snap-in (pél- 
dául Users and Computers) kapcsolatban áll. Minden AD 
snap-in esetében meghatározhatjuk, hogy melyik tarto- 
mányvezérlőt részesítse előnyben. A Users and Computers 
esetében például az Action menüben található Connect to 
Domain Controller paranccsal tudjuk ezt végrehajtani, 

"8 Use any available domain controller: Lehetőséget ad a Group 
Policy snap-in számára, hogy bármely rendelkezésre álló tar- 
tományvezérlőt igénybe vegye a házirend szerkesztésekor. 

A tartományvezérlő kiválasztásának imént ismertetett mód- 

jait a csoportos házirenden keresztül is be tudjuk állítani: 


User ConfigurationlAdministrative Templatesl 
D SystemiGroup PolicyiGroup Policy domain 


0 controller selection 


Ilyen esetben az operációs rendszer figyelmen kívül hagyja a 
Group Policy snap-in erre vonatkozó beállítását. Előfordulhat, 
hogy az előnyben részesített tartományvezérlő nem érhető el, 
ilyenkor hibaüzenetet kapunk. Ha a tartományvezérlő kivá- 
lasztását csak a Group Policy snap-inben határoztuk meg, ak- 
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kor az alábbi párbeszédablak jelenik meg, ahol lehetőségünk 
van megváltoztatni a korábbi beállítást. 





[Domain controller not found for Hypo.hu z 212 


The domain controler for Group Pobcy operations is not avadable. You may 
€9 cancel this operation for this session or rely using one of the following 

G [The one wihihe Öperations Master token fortha PDC emudati 

C Theone used by the Active Directory Snap-ns 

C Use any avalable domain controller 


ESET Eseti 





0 Ha a PDC emulátor nem érhető el, más GPO példányt 
is módosíthatunk 


Ezzel szemben, ha a kiválasztással kapcsolatban házirend van 
érvényben, akkor a következő figyelmeztető üzenet tűnik fel: 
aFailed to find a domain controller. There may be a policy 
that prevents you from selecting another domain controller." 
Ebben az esetben nincs lehetőségünk módosításra. 


Lokális csoportos házirend 

Minden Windows 2000 Professional munkaállomáson lehetősé- 
günk van beállítani helyi házirendet. A lokális Group Policy ob- 
jektum (LGPO) a 9oSystemRootJoSystem32AGroupPolicy map- 
pában helyezkedik el. Az ilyen típusú házirendobjektumnak ér- 
telemszerűen nincs Active Directorytól függő komponense. 
Az LGPO jogosultsági listájában nincs Apply Group Policy 
jog, ezért ha az Administrators csoportot mentesíteni akar- 
juk a helyi házirend hatásától, akkor a Read jogot meg kell 
vonnunk tőle. Ez viszont azzal a hátránnyal jár, hogy olva- 
sási jog nélkül a rendszergazdáknak nem lesz módjuk az 
LGPO tartalmát megtekinteni. 

A helyi csoportos házirendet is a Microsoft Management 
Console segítségével tudjuk szerkeszteni. Az MMC elindítá- 
sa után (mmc.exe) a Console menü Add/Remove snap-in 
parancsára kattintva nyílik lehetőségünk a Group Policy 
snap-int kiválasztására (Standalone fül, Add nyomógomb). 
Ezt követően az MMC alapértelmezésben a lokális házirend 
szerkesztésének lehetőségét kínálja fel. 


Standalone ( Fstnrzíre ] 
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Use ttis pi 
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Group Poácy Otjeets can be stored in the Aclíve 
Direciay ar on a local camozter 


Use the Browse button to select a Group Poácy 
Oteet 
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G1oxp Poány Otizct 
— 
Ké ess. Brome 
ZEIHLÁSESEI 17 Alom the focizz ot the Grosp Pokcy Snapn to. 
be changed mhen ieunching kom the command, 


ne. The only apokez í you zave the conscie 


0 [TT] ( eri 





o A helyi házirend módosítása MMC-vel 
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Ha a Finish nyomógombra kattintunk, akkor az aktuális mun- 
kaállomás házirendjét tudjuk szerkeszteni. Amennyiben egy 
távoli számítógép házirendjét szeretnénk módosítani, akkor 
a Browse gomb megnyomása után a Computers fülön választ- 
hatjuk ki a megfelelő munkaállomás nevét. 


A házirend végrehajtásának folyamata 

A számítógéphez rendelt házirend a gép elindítása, a felhasz- 
nálói beállítások pedig a bejelentkezés során érvényesülnek. 
Először mindig a LGPO, ezt követően a telephelyhez, majd a 
tartományhoz, végül a szervezeti egységekhez tartozó GPO-k 
végrehajtására kerül sor. Az alapértelmezett végrehajtási sor- 
rendet a korábban már említett Block Inheritance és a No 
Override parancsokkal megváltoztathatjuk. (Ezeket az utasí- 
tásokat a LGPO esetében nem használhatjuk.) 
Alapértelmezésben a beállítások végrehajtása szinkronizáltan 
történik. Ez a gyakorlatban azt jelenti, hogy a számítógép- 
függő házirend a bejelentkezési ablak megjelenése, a fel- 
használói pedig a felhasználói felület betöltődése előtt jut 
érvényre. Ezt a működési módot a 


Computer ConfigurationlaAdministrative TemplatesV 


0 SystemiGroup Policy 


alatt megváltoztathatjuk. A változtatás azonban nem aján- 
lott, mivel számos probléma forrása lehet. 

Újítás a Windows NT 4.0 System Policyjához képest, hogy a 
csoportos házirend beállításai bizonyos időközönként auto- 
matikusan frissülnek. Alapértelmezésben felhasználók és 
munkaállomások esetén ez az időtartam 90 perc, legfeljebb 
30 perces eltolódással, a tartományvezérlőknél pedig 5 perc. 
A Computer, illetve a User Configuration 


Nadministratiíve TemplatesMt 
) SystemiGroup Policy 


alatt lehetőségünk van ennek az értéknek a megváltoztatá- 
sára. Óvakodjunk azonban attól, hogy ezt az értéket túl ala- 
csonyra vegyük, hiszen ez növeli a hálózati forgalmat, vala- 
mint lelassíthatja a munkaállomás működését. Parancssorból 
is utasítást adhatunk a házirend frissítésére a 


secedit.exe /refreshpolicy MACHINE POLICY 


D [/enforce] 


illetve a 
secedit.exe /refreshpolicy USER POLICY [/enforcej] 


utasítás révén. Az enforce kapcsolónak csak a Security, il- 
letve az Encripted File System kiterjesztéseknél van hatá- 
sa: a beállítások akkor is frissülnek, ha a házirendben 
nem történt változás. 9 

Normális körülmények között a felhasználót követik a beállí- 
tásai, azaz bármelyik munkaállomáson is jelentkezik be, 
ugyanaz a felhasználói házirend lesz érvényes rá. A csopor- 
tos házirend azonban lehetőséget kínál arra, hogy a felhasz- 
nálói beállítások különbözzenek, attól függően, hogy melyik 
munkaállomáson jelentkezik be. Ezt nevezzük visszacsatolás 
(loopback) funkciónak, amelynek két fajtája van: 
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"B Merge mode: A hagyományos működésnek megfelelően 
először a felhasználóra, majd a munkaállomásra vonatko- 
zó beállítások hajtódnak végre. Ebből következően, ha 
átfedés van a kétféle házirend között, akkor a számító- 
géphez rendelt élvez elsőbbséget. 

Replace mode: Ebben az esetben csak a számítógépes ob- 
jektumhoz tartozó házirend lesz érvényes a felhasználóra. 
A visszacsatolás üzemmódot a 


Ve; 


Computer ConfigurationlAdministrative Templatel 


D SystemiGroup PolicyV 


alatt található , User Group Policy loopback processing mode" 
beállítással tudjuk engedélyezni. 

A csoportos házirend működésének áttekintése után nézzünk 
meg egy-két újdonságot közelebbről is. 


Programtelepítés Group Policyval 

Ez a funkció nagyon megkönnyítheti a rendszergazdák mun- 

káját, hiszen nem szükséges sok pénzért külön terméket vá- 

sárolni ahhoz, hogy a sok felhasználót érintő telepítéseket 
központilag el tudjuk végezni. 

1) A programtelepítés akkor a leghatékonyabb, ha a Windows 
Installer Service-en keresztül történik. Ennek előfeltétele, 
hogy rendelkezzünk a telepítést elősegítő úgynevezett 
Windows Installer csomaggal (.msi fájl). Abban az eset- 
ben, ha a program telepítőfájljai között nem találunk 
ilyen állományt, akkor két lehetőségünk van. Telepíthet- 
jük a szoftvert a Windows Installer használata nélkül is. 
Ekkor azonban több hasznos szolgáltatásról le kell mon- 
danunk. Például a szoftvert vagy a program egyik kompo- 
nensét nem telepíthetjük az első használatkor. Ráadásul 
el kell készítenünk egy .zap kiterjesztésű text állományt, 
amelyben kódoljuk a telepítés főbb elemeit (a setup.exe 

2) Ha nem ezt az utat választjuk, akkor el kell készítenünk a 
szoftverhez a megfelelő Windows Installer csomagot. Ezt 
a feladatot többféle alkalmazással is elvégezhetjük. Leg- 
kézenfekvőbb talán a Windows 2000 Server CD-n is meg- 
található VERITAS Winlnstall LE nevű programját igénybe 
venni. Használatához szükségünk lesz egy olyan számító- 
gépre, amelyiken az operációs rendszeren és a megfelelő 


szervizcsomagon kívül mást nem telepítettünk. Erre a 
gépre kell majd felraknunk azt az alkalmazást, amit majd 
szeretnénk elterjeszteni a vállalatunknál. A szóban forgó 
alkalmazás telepítése előtt és után le kell futtatnunk a 
Winlnstall Discover nevű segédprogramját, amely rögzíti 
a fájlrendszeren és a regisztrációs adatbázisban bekövet- 
kező változásokat. 

A Winlnstall segítségével nemcsak új csomagokat hozhatunk 

létre, hanem a már meglévőket módosíthatjuk is. (A VERITAS 

Winlnstall LE leírása megtalálható a Microsoft honlapján [1]). 


A programtelepítés fő lépései 

Először is a telepítendő állományokat, illetve a Windows Instal- 

ler csomagot másoljuk fel a kiszolgáló mindenki által elérhető 

(megosztott) mappájába (Software Distribution Point). Ezután 

válasszuk a céljainknak legmegfelelőbb telepítési módot: 

8 Publish to Users: Lehetőségünk van meghirdetni a telepí- 
tést a felhasználók számára. Ebben az esetben a felhasz- 
nálónak kell gondoskodnia a telepítés elindításáról a 
Control Panel -5 Add/Remove Programs -3 Add New 
Program segítségével. Ha olyan házirendobjektumnál en- 
gedélyezzük a szoftvertelepítést, amely már érvényben 
van a felhasználóknál, akkor nem kell a felhasználónak új- 
ra bejelentkeznie a telepítés indításához. Fontos tudni, 
hogy a felhasználók jogosultak a program eltávolítására is. 

2 Assign to Users: Az előző módszerhez képest, további 
szolgáltatás is rendelkezésünkre áll: a telepítés a program 
első használatakor is elindítható. A telepítendő program 
ikonja ugyanis a felhasználó bejelentkezését követően 
megjelenik a Start menüben. 

"B Assign to Computers: A telepítés a számítógép újraindítá- 
sához kötött, és a felhasználó beavatkozása nélkül megy 
végbe. Ilyenkor csak a lokális rendszergazdai jogosultság- 
gal rendelkezők tudják a programot eltávolítani. 

A telepítési módokat a Group Policy snap-in Computer vagy 

User Configurationt Software Settings mappa alatt tudjuk 

kiválasztani. 

Folytatjuk... 


Tomasz Balázs 
balazs.tomaszohu.hypovereinsbank.com 
pszichológus 


es LLP TISZA AGA 


[1] http://www.microsoft.com/windows2000/Llibrary/ planning/management/veritas.asp 
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BIZTONSÁG 


ISA Server -— 
bemelegítés m 


Ez a cikk az első része annak a cikksorozatnak, melyben azt 
szeretném bemutatni, hogy hogyan is lehet az ISA Server 
felhasználásával biztonságos rendszert felépíteni. Mivel 
több hónapos cikksorozatról van szó ejtsünk néhány szót a 
tervezett témákról: 

Alapvető tűzfalfunkciók megvalósítása: 

B SecureNAT 

A Server Publishing 

b Szűrők, tiltólisták 

A gyorsítótár: 

PI Láncok és tömbök 

DMZ kialakítása: 

0 DMZ kialakításakor mit vegyünk figyelembe 

0 ,két láb, vagy több láb" 

"0 mail relay 

Ph külső vagy belső webkiszolgálót telepítsünk 

Virtuális magánhálózatok: 

B ISA-ISA VPN 

I Ügyfél-ISA VPN 

Felhasználók azonosítása és hitelesítése 

0 tartomány 

"3 LDAP 

8 Kerberos 

0 RADIUS 


Együttműködés más gyártók termékeivel 

Jelen cikkem tulajdonképpen bevezető, mely a tűzfalakkal 
és az Internetes biztonság általános kérdéseivel foglalkozik. 
Természetesen a témákkal kapcsolatos észrevételeket és ja- 
vaslatokat szívesen fogadom (ezek közlésének pedig legegy- 
szerűbb módja a NetAcademia Tech.Net levelezési listája) . 
Sokakban felmerülhet a kérdés, hogy tulajdonképpen mi is 
a tűzfal. Jó kérdés! Mielőtt rátérnénk a tűzfalakra, tekint- 
sük át egy kicsit (tényleg csak egy kicsit) az OSI rétegeket 
(layer), és egy IP csomag szerkezetét. Hogy miért pont az 
IP csomagét? Egész egyszerűen azért, mert az Interneten 
folytatott kommunikáció legnagyobb része ilyen csomagok 
küldözgetéséből áll. 


Application 
Presentation 
Session 
Transport 
Network 
Data Link 
Physical 


elfrojulsjulja[ja 


5 Az OSI rétegek 
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Forrás Cél — Forrás — Cél Forrás Cél ADAT  CRC CRC CRC 
MAC MAC IPcím IP — port port (ellenőrző. (ellenőrző (ellenőrző 
cím cím cím összeg) — összeg) összeg) 


a Egy IP csomag (némiképp leegyszerűsített) szerkezete 


Amikor két számítógép IP kapcsolatot hoz létre, bizonyos 

információk beépülnek a hálózaton átmenő csomagokba. 

Ha a csomagokat egy erre szolgáló eszköz megállítja, meg- 

vizsgálja a benne levő adatokat, és ezek alapján eldönti, 

hogy mit kezdjen az adott csomaggal (átengedi vagy eldob- 
ja), akkor ez az eszköz egy tűzfal. 

Definíció: a tűzfal egy olyan hálózatok közti átjáró, amely 

rendelkezik egy szabályrendszerrel, és ezt a szabályrendszert 

kikényszeríti a rajta átmenő forgalmakon, ezzel megakadá- 
lyozva a rendszerekhez való illetéktelen hozzáférést. 

A fentiekből is látszik, hogy a tűzfal nem csodaszer. Nem 

képes például: 

"0 A belső hálózaton található fájlkiszolgálónkat megvé- 
deni a rosszindulatú belső felhasználóktól (a rosszindu- 
latú külső felhasználóktól viszont igen) 

"? Valódi vírusszűrést végezni 

"8 Önmagát beállítani, biztonságosabbá tenni (ezért kell 
behatolás-érzékelő (IDS) eszközzel kiegészíteni) 

-? Megvédeni a belső hálózatról modemező felhasználót 

(hiszen ez a kapcsolat nem megy át a tűzfalon) 

Kiégetni a rosszindulatért felelős idegsejteket a 

shekker" agyából :-) 

Viszont egy jó tűzfalszoftvernek mindenképpen képesnek 

kell lenni az alábbiakra: 

"B A rajta átmenő ÖSSZES forgalom ellenőrzése 

"1 Felhasználók hitelesítése 

"0 Tevékenységének ALAPOS naplózása (és nem hátrány az 
sem, ha ezek az eseménynaplók könnyen elemezhetők) 

"8 A fenti tevékenységeket pedig a szabályrendszer alap- 
ján kell végeznie 

-? Nem nélkülözhetetlen, de egyre inkább előtérbe kerül 
az is, hogy a tűzfalnak képesnek kell lennie titkosított 
adatkapcsolatok kiépítésére, és azok fogadására. 

Szóljunk néhány szót a tűzfalak előnyeiről is: 

"0 Magasszintű biztonság érhető el használatukkal. 

8 Meglehetősen költséghatékony megoldást jelentenek, 
hiszen egyetlen tűzfallal akár több ezer gépet is meg- 
védhetünk. 

"0 Mivel a hálózat határán helyezzük el a tűzfalat, a belső háló- 
zaton viszonylagos biztonságban érezhetjük magunkat. 

Nyilvánvaló, hogy (mint mindenhol) a tűzfalak esetében is 

a biztonság és a kényelmes felhasználás ellentétesek egy- 

mással. Néhány alapelv, aminek alkalmazásával tűzfalunk 

biztonságosabbá tehető: 


A 
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8 Minél kevesebb dolgot engedélyezünk tűzfalunkon, an- 
nál kisebb annak az esélye, hogy biztonsági rést ha- 
gyunk rajta. 

"8 A szabályrendszer legyen minél tömörebb, és (a lehető- 
ségekhez képest) jól áttekinthető. 

"B Kissé elcsépelt már, de nem lehet elégszer mondani (és 
a tűzfalnál különösen igaz): csak a feltétlenül szükséges 
szolgáltatások működjenek a tűzfalgépen. A tűzfal az 
tűzfal. Nem webkiszolgáló, nem fájlkiszolgáló, nem bár- 
mi más. CSAK tűzfal. 

Most már sok mindent tudunk a tűzfalak alapelveiről, lás- 

suk, hogy milyen konkrét megvalósítások léteznek! 

A tűzfalaknak több típusa létezik, manapság már egyre rit- 

kább az, hogy egy adott tűzfalszoftver tisztán az alábbi ka- 

tegóriák valamelyikébe besorolható legyen: 

2 Csomagszűrők 

B Állapottáblás csomagszűrő 

"B Proxy 

"8 Címfordítók 

Ezek a főbb műszaki megvalósítások, alapelv szerint pedig 

kétféle tűzfalat különböztetünk meg: 

"8 Megengedő: ez gyakorlatilag azt jelenti, hogy ha a sza- 
bályrendszerében nincs az adott kapcsolatra megfelelő 
definíció, akkor azt átengedi magán, vagyis: , Mindent 
szabad, amit nem tilos." 

"0 Tiltó: magától értetődően ez az előző ellentéte, tehát: 
"Mindent tilos, amit nem szabad." Ez az elterjedtebb 
alapfilozófia. 


Csomagszűrő tűzfalak 

Ezek a tűzfalak a csomagokat önálló egységként kezelik. Tu- 

lajdonképpen a szűrés megvalósításához ötféle információ 

áll rendelkezésre: 

"8 Forrás IP cím 

-8 CélIP cím 

0 Forrás port 

9 Cél port 

"0 A szolgáltatás típusa (például TCP, UDP) 

Előnyeik: 

"1 Viszonylag egyszerű eszköz, gyakorlatilag bármely útvo- 
nalválasztó (router) eszközzel megvalósítható 

"0 A felhasználó számára észrevétlen (persze csak addig, 
amíg nem ütközik valamilyen tiltó szabályba) 

"0 Gyors, mert a szűrés egyszerűsége miatt kicsi a teljesít- 
ményigény 

Hátrányaik: 

0 Jól beállítani igen nehézkes (egy szabályt körülbelül úgy 

kell elképzelni, hogy megadjuk a fenti öt információt 

minden szűrni kívánt forgalomhoz, és ezek alapján meg- 

mondjuk, hogy engedélyezzük-e az adott forgalmat, vagy 

nem), és a beállítások helyességéről nehéz megbizo- 

nyosodni. 

Mivel a cél és a forrás azonosítása az IP cím (esetleg a 

fizikai cím) alapján történik, a többi tűzfalhoz képest 

könnyebb kijátszani 

A csomagszűrők mai megjelenési formái jellemzően az 

útvonalválasztó eszközök. Ezek viszont nem arról híre- 

sek, hogy szinte korlátlan tárolókapacitással rendelkez- 

nek, ezért a képződő eseménynaplókat el kell juttatni 


b 
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valamilyen másik eszközhöz. Ez a naplózást, és a nap- 
lók elemzését bonyolultabbá teszi. 


Állapottáblás csomagszűrők (stateful packet filter) 

Ez a tűzfaltípus tulajdonképpen a csomagszűrők továbbfej- 

lesztett változata. Annyival tud többet, hogy a felépített 

kapcsolatokat állapottáblák (state table) használatával 

nyilvántartja. Ez a gyakorlatban azt jelenti, hogy alapálla- 

potban a szabályrendszernek megfelelően az összes portot 

blokkolja. Amikor valaki kapcsolatot akar nyitni például egy 

webkiszolgáló felé (most lényegtelen, hogy kifelé, vagy be- 

felé irányuló kapcsolatról van szó), akkor - ha ez engedé- 

lyezve van - megnyitja a kapcsolatot, de a kiszolgálótól 

visszakapott csomagokat csak akkor engedi át, ha erre az 

állapottáblában megfelelő bejegyzést talál. A kapcsolat le- 

zárása után a port ismét bezárul. 

Előnyeik: 

8 A felhasználók számára észrevételen 

"8 Nemcsak csomag-, hanem kapcsolatszinten is képes 
vizsgálni a rajta átmenő forgalmat 

8 Jó teljesítmény 

- Minden protokollt lehet szűrni vele (hiszen ha ismerjük 
a protokoll jellemzőit, például azt hogy a kapcsolat kiépü- 
lése után a kiszolgáló milyen porton akar az ügyfél felé 
kapcsolatot nyitni, akkor azt biztosan tudjuk szűrni is) 

0 Jólintegrálható más megoldásokkal 

"0 Az állapottábla használata 

"8 A felhasználó azonosítása és hitelesítése is elvégezhető 

8 Könnyen bővíthető (, csak" definiálni kell az új proto- 
kollt, és már működhet is) 

0 Általában címfordítást végez (lásd később), ezzel elrej- 
ti a belső hálózat felépítését 

Hátrányaik: 

"8 Nem ,bontja" a kapcsolatot (lásd a proxy tűzfalaknál) 

Igazából az egyetlen felemlíthető hátrány egyrészről a biz- 

tonság rovására megy, másrészről viszont jelentősen növe- 

li a teljesítményt. Jellemzően ezt a megvalósítást sem 

használják önmagában, hanem a gyakran használt pro- 

tokollokra (főleg HTTP, SMTP, FTP) proxy-kat alkalmaznak. 

Már sokat emlegettük a proxy-kat, lássuk hát mik is ezek. 


Proxy tűzfalak: 

A proxy tűzfalakat szokták application layer gateway-ként (al- 
kalmazás rétegben működő átjáró) is emlegetni. Bármilyen 
meglepő is, ez az elnevezés nem véletlen. Ez a megoldás 
ugyanis az OSI rétegek közül a legfelsőben, az alkalmazásré- 
tegben végez szűrést. Ez egyben azt is jelenti, hogy a szűrő 
az adott protokoll MINDEN jellemzőjét ismeri, és ha bármilyen 
szabálytalanságot észlel, azonnal elkaszálja az adott kapcso- 
latot. A megvalósítás másik fontos jellemzője az, hogy a pro- 
xy tűzfal bontja a kapcsolatot. Lássuk mit is jelent ez: 
Maradva kedvenc webkiszolgálós példánknál, a belső hálóza- 
ton levő ügyfél meg akar nézni egy külső webkiszolgálón le- 
vő weblapot. Elmegy a tűzfalhoz. A tűzfal fogadja a kapcsola- 
tot, és megjegyzi, hogy mit is kért az ügyfél. Ezután az ügy- 
fél nevében eljárva, a saját IP címét használva megnyitja a 
kapcsolatot a webkiszolgáló felé, és megszerzi a kért adato- 
kat. A kapott tartalmon teljeskörű protokoll-ellenőrzést végez 
(mintha ő maga lenne az ügyfél), és ha mindent rendben ta- 
lált, csak akkor továbbítja az ügyfél felé a kért adatokat. 
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Itt az ideje, hogy eloszlassak egy tévhitet (tisztelet a kivé- 
telnek, vagyis annak, aki nem tévhitt :-) ). Sokan úgy gon- 
dolják, hogy a proxy az szükségszerűen gyorsítótár (cache) 
is. Ez ebben a formában nem igaz! A gyorsítótárat azért ta- 
lálták ki, mert a proxy tűzfalak egyik nagy hátránya éppen 
teljesítményigényük (bár a mai gépek mellett ez egyre kevés- 
bé jelent problémát). Könnyen spórolható meg jókora telje- 
sítmény, ha a már átvizsgált, és még aktuális tartalmakat a 
tűzfalgép merevlemezén tároljuk, és a későbbi kéréseket in- 
nen szolgáljuk ki. Természetesen a gyorsítótár nagyon hasz- 
nos, és egyre fejlettebb megoldások állnak rendelkezésünk- 
re, hogy gyorsítótárunkat, és ezzel együtt Internetkapcsola- 
tunk sávszélességét minél jobban kihasználhassuk. 


A proxy tűzfalak előnyei: 

0 A legmagasabb szintű biztonságot ez a megoldás ga- 
rantálja 

0 A belső hálózatot elrejti 

0 A kifelé menő kérések a tűzfal IP címéről érkeznek, így 
egyetlen támadható IP címet mutatunk magunkból. Ha 
támadnak, így a tűzfalat támadják. 

0 Nemcsak magát a kapcsolatot, de annak tartalmát is 
vizsgálja 

-P Általában jár hozzá a gyorsítótár 


A proxy tűzfalak hátrányai: 

"0 A felhasználók számára nem átlátszó (általában) 

2 Használatához gyakran speciális ügyfélprogramra van szükség 

"0 Nagy teljesítményigény (a gyorsítótár használatával ez 
jelentősen csökkenthető) 

"0 Minden szolgáltatáshoz külön proxy kell 

0 Nehezen bővíthető, emiatt lehet, hogy nem tudja a 
legújabb protokollmegvalósításokat 
(lásd SMTP és ESMTOP). 

A proxy-k kétféle üzemmódban működhetnek, ez az üzemmód 

tulajdonképpen a felépítendő kapcsolatok irányától függ. 


Forwarding proxy 

Ez az üzemmód a ,klasszikus" felállás. A tűzfal a hálózat 
határán helyezkedik el, és a belső hálózatról érkező kérése- 
ket továbbítja a külvilágban található rendeltetési helyre. 


Reverse proxy 

Ez pedig, mint a neve is mutatja, fordított üzemmódban 
működik. Vagyis: itt az ügyfelek az Interneten vannak, és 
a saját kiszolgálók felé továbbítódnak a kérések. Nyilván- 
való előny, hogy magához a kiszolgálóhoz közvetlenül nem 
érkezhetnek kérések, így az igen jól védett környezetben 
működhet. Az ilyen megoldások az ügyfelek számára álta- 
lában átlátszóak, az ügyfél nem is tudja, hogy nem közvet- 
lenül a kiszolgálóval folytat kommunikációt 


A címfordító (NAT) tűzfalak: 

A címfordító eszközöket sokan nem is tekintik tűzfalnak 
(viszont a tűzfalmegoldások technikai megvalósításánál mu- 
száj megemlíteni a címfordítást, és ez itt nagyon jó helynek 
látszott :-) ). Miről is van szó? Tulajdonképpen arról, hogy 
a címfordítást végző eszköz az IP csomagban kicseréli va- 
lamelyik (lásd később) IP címet, és esetlegesen a portot is. 
Lássuk, milyen címfordításokat végezhetünk: 
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Dinamikus címfordítás 

Ezt általában a belső hálózatról kifelé igyekvő ügyfelek 
esetén alkalmazzuk. Amikor dinamikus címfordítást vég- 
zünk, akkor a címfordító eszköz egyetlen érvényes IP cím 
mögé (nem szükségszerűen a saját érvényes IP címe) rejti 
el az ügyfelet. Jogos a kérdés, hogy hogyan is teszi ezt. 
Egészen egyszerűen kicseréli a forrás IP címet (szükség 
esetén a forrás portot is) a csomagokban, így a válaszok er- 
re a megváltozott címre fognak érkezni. Természetesen az 
eszköznek meg kell oldania azt is, hogy ezek a csomagok 
visszajussanak az ügyfélhez, vagyis a kapcsolat idejére 
meg kell jegyeznie, hogy milyen címet (esetleg portot) mi- 
vel cserélt ki és hová irányult az adott kapcsolat. 


Statikus célcím-fordítás 

Mint talán nevéből is sejthető, mindig az egy adott címre 
érkező csomagokban levő célcímet cseréli ki, egy előre 
meghatározott címre. Mire is használható ez a gyakorlat- 
ban? Maradjunk a webkiszolgálós példánál, de azzal a vál- 
tozással, hogy legyen a kiszolgáló a belső hálózaton, és le- 
gyen privát címe. Nyilvánvaló, hogy csak akkor tudnak a 
webkiszolgáló felé kéréseket küldeni, ha van egy nyilvános 
címe is. Akkor most rakjuk ki az Internetre? A világért sem! 
Hiszen itt a kiváló tűzfalunk (vagy legalábbis címfordító 
eszközünk)! Akkor mit is teszünk? A DNS-ben megadunk a 
webkiszolgálónak egy nyilvános IP címet, és az erre a cím- 
re érkező kérések cél IP címeit pedig kicseréljük a webki- 
szolgálónk privát címére. És íme, a kérések már érkeznek is 
a webkiszolgálóhoz. (Vigyázat! Ez a megoldás önmagában 
NEM FOKOZZA A BIZTONSÁGOT!!! Fontos, hogy a tűzfal sza- 
bályrendszerében ezekre a kapcsolatokra legyen valamilyen 
szűrés, vagy készítsük fel a kiszolgálót az esetleges támadá- 
sok túlélésére.) Szóval ott tartottunk, hogy a kérések 
megérkeznek a kiszolgálóhoz. De vajon a válaszok kimen- 
nek? Nem (vagy ha igen, akkor majd az első helyesen beál- 
lított útvonalválasztó ,,elkaszálja" őket a privát IP cím 
miatt) . Ezért van szükségünk a: 


Statikus forráscím-fordításra 

Ami pedig magától értetődően az előző ellentéte, vagyis az 
adott belső címről érkező csomagok forrás IP címeit kicse- 
réljük az előre meghatározott külső IP címre. Most már min- 
denki megnyugodhat? Igen. A webkiszolgálónk megkapta a 
kéréseket, a külső ügyfél pedig a kért weblapokat. Hurrá! 
Mint az már az előzőekben is elhangzott, gyakorlatilag nincs 
olyan eszköz a piacon, amely az egyes funkciók (csomagszű- 
rés, állapottáblás csomagszűrés, proxy, címfordítás) közül 
csak az egyiket tartalmazná. Jelenleg a legegyszerűbb tűz- 
faleszközök azok az útvonalválasztók, melyek rendelkeznek 
csomagszűrő képességgel, és tudnak címfordítást végezni. A 
fejlettebb, bonyolultabb, igazán tűzfalnak tekinthető rend- 
szerek pedig általában a proxy-k, az állapottáblás csomag- 
szűrők, és a címfordítás előnyeit kihasználva működnek. 


Ki, és mi ellen is védekezünk? 

Most már ismerjük a tűzfalmegoldások alapjait. Ha hatéko- 
nyan akarjuk megvédeni hálózatunkat, tudnunk kell azt is, 
hogy ki, és milyen támadástípusok ellen védekezünk. E cikk 
keretei nyilván nem elegendőek arra, hogy minden támadástí- 
pust részletesen ismertessünk, hiszen ezzel akár egy teljes 
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könyvet is meg lehetne tölteni, de azt mindenképpen szüksé- 


gesnek érzem, hogy legalább a legfontosabbakat megemlítsem. 


Ki ellen? 

A hálózatokra támadókat sokféleképpen lehetne csoportosí- 
tani, én most a következő kategóriákat tartanám fontosnak 
(szándékosan nem fordítom le a megnevezéseket, mert egy- 
részt nem igazán lehet visszaadni az eredeti szó jelentését, 
másrészt ezek már elég elterjedtek) : 


Hacker 

Ő csak a kihívást keresi, általában nem akar, és ezért nem 
is okoz kárt, hiszen jól felkészült szakemberről van szó. Na- 
gyon alaposan ismeri a védelmi rendszereket, a protokollo- 
kat, és ezek gyengeségeit. ,Fegyvertárát" saját maga fej- 
leszti. Ha bejutott a rendszerünkbe, általában ügyesen 
megsemmisíti ennek nyomait, esetleg külön felhívja a fi- 
gyelmet ,hőstettére". 


Professzionális hacker 

Ez egy kissé új keletű fogalom. A hacker-hez hasonló, vi- 
szont neki ez a ,szakmája". Gyakorlatilag információkat 
lop, ezeket adja el. Ne tessék nevetni, ez létező dolog! 


Cracker 
Olyan mint a hacker, de ő az anarchista változat. Általában 
tevékenységének egyetlen célja a rombolás. 


Script kiddie 

Ők azok a hülyegyerekek (már bocsánat), akik letöltenek az In- 
ternetről mindenféle , játékokat", majd ráeresztik azokat a ki- 
szemelt rendszerre, vagy kiszolgálóra. Tudásuk nem túl nagy, 
éppen ezért gyakran azt sem tudják, hogy mivel is játszanak". 
Talán ők a legveszélyesebbek, viszont őket lehet legjobban ki- 
szűrni egy jól beállított, és naprakészen tartott tűzfallal. 


Ártatlan áldozatok 

Nem, ez nem tévedés. Bizony olyanok is támadhatnak ránk, 
akik maguk is ártatlan áldozatok. Ehhez mindössze annyi 
szükséges, hogy a gépükre bejusson egy trójai program, amely 
egy adott időben meghatározott tevékenységet hajt végre. A 
DDOS támadások ,elkövetői" általában maguk is áldozatok (a 
valódi elkövető pedig az, aki a trójai programot elkészítette) . 


Mi ellen? 

Itt most csak érdekességképpen említenék néhány táma- 
dástípust a teljesség igénye nélkül. Akit ennél mélyebben 
érdekel a téma, annak érdemes részt venni a NetAcademia 
biztonsági tanfolyamain. Mindegyik támadástípusnál igye- 
keztem feltüntetni, hogy mi kivédésének legjobb módszere, 
ami azonban mindegyikre érvényes az az, hogy odafigyelés- 
sel jelentősen csökkenthető a sikeres támadás esélye. 


DOS (Denial of Service — a szolgáltatás megszűnése) támadás 
Olyan támadási forma, melynek egyetlen célja az, hogy egy 
adott kiszolgáló ne tudjon szolgáltatást nyújtani. Elérhető 
például azzal, hogy egy operációs rendszer, protokoll, vagy 
az operációs rendszeren futó szolgáltatás egy gyengeségét 
kihasználva a processzor terhelése tartósan 1009o-os lesz, 
vagy nemes egyszerűséggel , lefagy" a gép. De még ez sem fel- 
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tétlen szükséges. Elég normális, szabályos kérésekkel bombáz- 
nunk a kiszolgálót, csak annyi a lényeg, hogy ebből sok legyen! 
Védekezni ez ellen a támadási forma ellen naprakészséggel 
lehet leginkább. 


DDOS (Distributed Denial of Service) 

A DoS támadás egy fajtája, azzal a különbséggel, hogy itt ren- 
geteg ,támadó" van (ezért Distributed, vagyis elosztott). Egy 
ilyen megvalósításához nem is kell mást tenni, csak sok fel- 
használó gépére bejuttatni egy trójai programot, amely egy 
előre megadott időpontban elkezd kérésekkel bombázni egy 
adott webkiszolgálót. Ha elegendő helyre sikerült bejuttatni 
a trójait, szinte biztos a siker. A védekezés szinte lehetetlen. 


Behatolás (Intrusion) 

Most csak a hálózatba történő behatolásról beszélek. Ez ön- 
magában nem okoz kárt, sőt, ha nem rosszindulatú a támadó, 
esetleg egy e-mail-ben felhívja figyelmünket rendszerünk 
gyengeségére. Az ilyen figyelmeztetéseket mindig vegyük na- 
gyon komolyan! Rengeteg példa van ugyanis arra, hogy a má- 
sodik figyelmeztetés már komoly károkozással is együtt jár. 


Információlopás 
Ez lehet a behatolást követő lépés. Védekezni ellene csak 
úgy tudunk, ha a bizalmas adatainkat nagyon jól védjük. 


Social engineering 

Ennek sincs igazán jó magyar megfelelője. Itt igazából az em- 
beri butaság/képzetlenség kihasználásáról van szó. Tipikus pél- 
dája ennek, hogy felhívnak egy felhasználót, hogy ugyan már, 
tesztelési céllal árulja el a jelszavát, vagy csak egész egysze- 
rűen leolvassák a jelszót a monitorra ragasztott kis sárga papír- 
fecniről. Védekezni ellene a felhasználók képzésével lehet. 


Valaki más megszemélyesítése (spoofing) 

Képzeljük el azt az esetet, amikor valaki egy általunk meg- 
bízhatónak ítélt webkiszolgáló helyett kezdi el működtetni 
saját kiszolgálóját. Rengeteg káros kódot juttathat be így 
hálózatunkba. 

Ennyit az általánosságokról. Bár ezzel még korántsem teljes 
a kép, az ISA Server kiépítésének egyes lépéseinél ki fogok 
térni a még hiányzó dolgokra. 

A jövő hónapban az ISA Server telepítéséről, és az alapve- 
tő funkciók (kiszolgáló publikálása, SecureNAT, alapvető 
mindenkinek, hogy olvassa a NetAcademia security levele- 
zési listáját, hiszen itt az egyes problémák konkrét megol- 
dása mellett naprakészen tájékozódhat a legújabb felderi- 
tett biztonsági lyukakról, és ,befoltozásukról". 
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A ForestPrep és a DomainPrep 

A Microsoft Exchange 2000 Server címtárként a Windows 
2000 Active Directory-t használja. Az Active Directory adat- 
bázisának szerkezetét a séma írja le, mely alaphelyzetben a 
Windows 2000 tartományvezérlő funkciók ellátásához szük- 
séges adatok tárolását teszi lehetővé. Az Exchange 2000 te- 
lepítéséhez tehát elő kell készíteni az Active Directory cím- 
tárat. Ezt a legtöbb esetben a telepítéssel egy időben, ma- 
ga a telepítőprogram elvégzi, de vannak bizonyos esetek, 
amikor az Exchange 2000 telepítése előtt kell felkészíte- 
nünk az Active Directory-t az Exchange fogadására. Erre 
szintén az Exchange 2000 kiszolgáló telepítőprogramját 
használhatjuk két parancssori kapcsolóval: 


setup /ForestPrep 


setup /DomainPrep 


Most összefoglaljuk mindkét parancssori opció működését, 
valamint a futtatásukhoz szükséges jogosultságokat. Megis- 
merjük, mire kell ügyelnünk a ForestPrep és a DomainPrep 
futtatása előtt. 


Miért van szükség a ForestPrep és DomainPrep futtatására? 
Általában a nagyvállalatok az üzenetküldő rendszereket ke- 
zelő rendszergazdáknak nem akarnak magasszintű tartomá- 
nyi vagy vállalati jogosultságokat adni, a legtöbb esetben az 
Exchange rendszergazdák egy külön csoportban dolgoznak a 
helyi hálózatot felügyelő és karbantartó kollégáiktól. A sa- 
ját címtárral rendelkező Exchange 5.5-öt használó vállala- 
toknál könnyen szétválaszthatók a tartományi és az üzenet- 
küldő rendszerrel kapcsolatos rendszergazdaszerepek, de az 
Exchange 2000 a Windows 2000 Active Directory címtárát 
használja, így körültekintően kell beállítani a kétfajta sze- 
rephez szükséges jogosultságokat egyazon adatbázisban. 
Ahol ez a szétválasztás fontos - a ForestPrep és a DomainP- 
rep - el lehet különíteni a magasszintű hálózati jogosultsá- 
gokat igénylő sémamódosítást és a címtárbeli jogosultsá- 
gok beállítását az alacsonyabb szintű jogosultságot igény- 
lő Exchange 2000 Server telepítésétől. 

A Windows 2000 EnterpriseAdmin és SchemaAdmin jogokkal 
rendelkező rendszergazdák futtathatják a ForestPrep opcióval 
az Exchange 2000 telepítő programját, melynek során létre- 
hoznak egy felhasználói fiókot az Exchange 2000 leendő 
rendszergazdája számára. Ez az Exchange rendszergazda a Fo- 
restPrep és a DomainPrep futtatása után elegendő tartományi 
jogosultságokkal rendelkezik az Exchange 2000 telepítéséhez, 
így már csak a helyi gépen kell rendszergazdának lennie. 

A jogosultsági kérdéseken kívül egy másik praktikus ok, ami 
miatt külön kell futtatnunk a ForestPrep-et, hogy a sémát 
az Active Directory erdőben csak egy helyen, a Schema Mas- 
ter gépen módosíthatjuk. Így ha az első Exchange 2000 te- 
lepítését nem azon a telephelyen vagy tartományban vé- 
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geznénk, ahol ez a Schema Master található, akkor nagy va- 
lószínűséggel a telepítő azt nem fogja tudni elérni vagy fi- 
zikai, vagy jogosultsági okokból, így a sémamódosítást nem 
tudjuk végrehajtani. 


ForestPrep 

Nézzük meg részletesen, hogy hogyan működik az Exchange 
telepítő ForestPrep opciója. A ForestPrep végrehajtja az 
összes olyan Exchange 2000 telepítési feladatot, amelyhez 
EnterpriseAdmin és SchemaAdmin jogosultságok, illetve a 
Schema Master gép elérése szükséges. Exchange-specifikus 
információk tárolásához szükséges osztályokkal, attribútu- 
mokkal és speciális jogosultságok definícióival bővíti az Acti- 
ve Directory sémáját, valamint objektumokat hoz létre az Ac- 
tive Directory konfigurációtárolójában (Configuration Partiti- 
on), és ezekhez az objektumokhoz a leendő Exchange rend- 
szergazdai fiók számára megfelelő hozzáférési jogokat ad, így 
ez a rendszergazda most már elegendő jogosultsággal fog 
rendelkezni az első Exchange 2000 telepítéséhez. 
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0 Az Exchange rendszergazda jogosultságai az Exchan- 


ban ForestPrep után 


A ForestPrep által az Exchange 2000 rendszergazda számá- 
ra létrehozott felhasználói fiók ugyanazokkal a jogosultsá- 
gokkal rendelkezik, mint a majdani kész Exchange 2000- 
ben az Exchange Administration Delegation Wizard által 
szervezeti szinten létrehozott Exchange Full Administrator. 
A ForestPrep-et Windows 2000 erdőnként elég egyszer fut- 
tatni, ekkor a sémát - ami a teljes erdőre vonatkozik - mó- 
dosítja, létrehozza, és bejegyzi az Exchange szervezet ne- 
vét és objektumát az Active Directory-ba. 
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BACKOFFICE )b AZ EXCHANGE 2000 És AZ 
A ForestPrep segítségével létrehozott Exchange rendszer- 
gazdának ugyan van joga telepíteni az Exchange 2000-et, 
de ezzel a felhasználói fiókkal alaphelyzetben nem lehet to- 
vábbi felhasználói vagy levelezési fiókokat létrehozni. Ha 
ehhez szükséges jogokkal is fel kívánjuk ruházni az Exchan- 
ge rendszergazdát, akkor több lehetőségünk van. Adhatunk 
rendszergazdai jogokat a Windows felhasználói fiókok létre- 
hozásához és kezeléséhez ennek a fióknak, ha hozzáadjuk az 
Account Operators csoporthoz. Vagy használhatjuk a Win- 
dows 2000 Delegation of Control Wizard-ot, amellyel enge- 
délyezhetjük az Exchange rendszergazdának a Users tároló 
objektumainak kezelését. Az is megoldás lehet, hogy egy új, 
speciális szervezeti egységet hozunk létre az Exchange fel- 
használók számára, és az Exchange rendszergazdának csak 


A ForestPrep futtatása előtt 

Néhány információt össze kell gyűjtenünk a ForestPrep futta- 
tása előtt, mivel különböző kérdéseket fog feltenni attól füg- 
gően, hogy ez egy új Exchange 2000 szervezet telepítése 
lesz, vagy egy létező Exchange 5.5 szervezetbe integráljuk. 


Új telepítés 

Az Exchange 2000 Server új szervezetbe történő telepítésé- 

hez a hálózati rendszergazdának az alábbi információkra 

van szüksége a ForestPrep futtatása előtt: 

0 Az új Exchange 2000 szervezet neve 

"0 Annak a felhasználói fióknak a neve, aki az Exchange 
2000 kiszolgálót telepíteni fogja. 


Telepítés Exchange 5.5 szervezetbe 

Egy már meglévő Exchange 5.5 szervezetbe történő telepí- 

téshez a hálózati rendszergazdának az alábbi információkra 

van szüksége a ForestPrep futtatása előtt: 

"0 Egy olyan Exchange 5.5 kiszolgálónak a neve, ami azon 
Exchange telephelyen (Site) van, amelybe az Exchange 
2000-et telepíteni szeretnénk 

"8 Exchange 5.5 szolgáltatási fiók és jelszó 

A megnevezett Exchange 5.5 kiszolgálónak üzemelnie kell és 

legalább a Service Pack 3-nak telepítve kell lennie rajta, va- 

lamint az Active Directory Connector (ADC) Exchange 2000 

Server CD-n található változatának telepítve kell lennie az 

erdőben. Az Exchange 5.5 SP3 szolgáltatja a ForestPrep se- 

gédprogramnak az Exchange 5.5 szervezet információit. 

Van némi átfedés a hálózati és az Exchange jogosultságok 

között az Exchange 5.5 telephelybe történő telepítés esetén, 

hiszen a ForestPrep-et futtató fióknak Admin jogosultsággal 

kell rendelkeznie mind az Exchange 5.5 telephelyhez, mind a 

telephely konfiguráció tárolóján (Site Configuration Contai- 

ner). Mivel az Exchange 5.5 a Windows 2000 Active Directo- 
ry-tól eltérő, saját címtárral rendelkezik, az EnterpriseAdmin 
jogosultság nem érvényes az Exchange 5.5 kiszolgálóra. 


Milyen követelményei vannak a ForestPrep futtatásának? 

A ForestPrep futtatásához az alábbi feltételeknek kell 

teljesülniük: 

8 A ForestPrep-nek a Schema Master-rel közös tartomány- 
ban kell futnia (alaphelyzetben ez a gyökértartomány — 
root domain), és el kell tudnia érni a Schema Master gépet 
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"8 A ForestPrep-et futtató személynek tagja kell lennie az 
Enterprise Admins és a Schema Admins csoportoknak 

"B Exchange 5.5 telephelybe történő telepítéskor a Fo- 
restPrep-et futtató fióknak Admin jogosultsággal kell 
rendelkeznie a telephelyobjektumon és a telephely- 
konfiguráció tárolóján is. 


Mikor futtassuk a ForestPrep segédprogramot? 

A legtöbb bevezetési forgatókönyvben szükség van a Fo- 
restPrep futtatására a sikeres Exchange 2000 telepítéshez. 
Akkor feltétlenül, ha az Exchange rendszergazdának nincs 
EnterpriseAdmin és SchemaAdmin jogosultsága, illetve a 
fenti követelmények közül bármelyik nem teljesül. 

Az Exchange 2000 telepítéshez, az Exchange rendszergazdá- 
nak rendszergazdai jogokkal kell rendelkeznie a helyi kiszol- 
gálón és ezeket a jogokat engedélyeznie kell a ForestPrep 
számára is. Azonban ez teljesül, ha a rendszergazda a Do- 
main Admins csoport tagja, mert e csoport tagjainak alap- 
helyzetben rendszergazdai jogosultságuk van a tartomány 
összes számítógépén. 

Egy Exchange 2000 komponens telepítése - a Key Manage- 
ment Server - ehhez képest több jogot követel meg, itt nem 
elég helyi rendszergazdának lenni, hanem Domain Admi- 
nistrators csoport tagjának is. 

Ha az Exchange 2000 telepítése majd gyermektartomány- 
ban történik, akkor a ForestPrep segédprogramot először a 
szülőtartományban futtassuk. Ha ezt nem tesszük meg, a 
telepítő figyelmeztetni fog erre. 


Mikor felesleges futtatni a ForestPrep segédprogramot? 
A ForestPrep-et a vállalat felépítésétől függően, az első 
Exchange 2000 kiszolgáló telepítése előtt kell általában fut- 
tatni. Azonban van néhány kivétel (általában a kisvállalatok- 
nál) amikor a ForestPrep használata nem szükséges. 

A ForestPrep és a DomainPrep a telepítéskor automatikusan 
elindul, de csak akkor tud sikeresen lefutni, ha az Exchange 
rendszergazdai fiók a Schema Admins és az Enterprise Ad- 
mins csoportok tagja és az első Exchange 2000 kiszolgáló 
ugyanabban a tartományban van, mint a Schema Master. Ha 
a feltételek nem teljesülnek, a telepítő hibajelzéssel megáll. 
Ebben az esetben nem szükséges kézzel elindítani a telepí- 
tést egyik előkészítő opcióval sem. Ilyenkor a telepítőt fut- 
tató felhasználói fiók lesz alaphelyzetben az Exchange 2000 
rendszergazdai fiókja. 


A replikációhoz szükséges idő 

A ForestPrep futtatása után győződjünk meg arról, hogy el- 
telt-e elegendő idő az adatbázis séma replikációjára az 
egész tartományban és a teljes erdőben. A vállalat földrajzi 
elhelyezkedésétől és a Windows 2000 telephelyek (Site) és 
tartományok közötti hálózati kapcsolat sebességétől füg- 
gően ez némi időt vehet igénybe. Csak abban az esetben 
futtassuk a DomainPrep segédprogramot, vagy a teljes tele- 
pítést, ha megbizonyosodtunk arról, hogy az Exchange-spe- 
cifikus információk replikálása a teljes rendszerben megtör- 
tént. A replikáció megtörténtéről úgy tudunk meggyőződni, 
hogy ellenőrizzük az 1575-ös esemény bekövetkeztét a cím- 
tárnaplóban, vagy megnézzük az ADSIEdit segédprogrammal 
a cn-ms-Exch-Schema-Version-Pt objektum rangeUpper pa- 
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raméterét. Ha ez kisebb, mint 4397, vagy nem létezik az 
objektum, akkor még nem futott le a séma replikációja. 
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0 Az AD séma verziójának ellenőrzése 


DomainPrep 

A DomainPrep végrehajtja azokat az Exchange telepítési 
feladatokat, amelyekhez DomainAdmin jogosultságra van 
szükség. A DomainPrep-et minden Exchange 2000 kiszolgá- 
lót, vagy Exchange felhasználókat tartalmazó tartomány- 
ban csak egyszer kell lefuttatni. (Azt az Exchange tarto- 
mányt, amely levelezőfelhasználókat tartalmaz, de Exchange 
kiszolgálót nem, felhasználói tartománynak hívjuk.) Ez a se- 
gédprogram létrehozza az Exchange kiszolgáló üzemelteté- 
séhez szükséges csoportokat és a felhasználói attribútumok 
olvasásához és módosításához szükséges jogosultságokat. 
A DomainPrep két új csoportot hoz létre: az Exchange Do- 
main Servers (Windows 2000 globális biztonsági csoport) és 
az Exchange Enterprise Servers (Windows 2000 tartomány 
helyi biztonsági csoport). 

A DomainPrep ezen kívül létrehoz egy Public Folder tárolót 
az Active Directory-ban. Míg a ForestPrep az egész erdőre 
kiterjedő konfiguráció-tárolóban dolgozik, a Public Folder 
objektum — a Microsoft Exchange System Objects — a 
tartománypartícióban található. A DomainPrep létrehozza 
ezt a tárolót minden tartományban, ahol lefuttatjuk. 
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0 A DomainPrep által létrehozott csoportok viszonya 
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Az Exchange Domain Servers csoport 

Az Exchange Domain Servers globális biztonsági csoport 
tartalmazza a tartomány összes Exchange kiszolgálójának 
számítógépfiókját. Bár ezt is a DomainPrep hozza létre, az 
Exchange Domain Servers csoport nem látható a tartomány 
első Exchange 2000 kiszolgálójának telepítéséig. 

Az Exchange Domain Servers csoport szükséges a Recipient 
Update Service használatához, amire szükség van az 
Exchange szervezet minden egyes tartományában. Ebbe 
beletartoznak a felhasználói tartományok is, amelyek leve- 
lező felhasználókat tartalmaznak, de Exchange kiszolgáló- 
kat nem. A Recipient Update Service szolgáltatást az 
Exchange az alapértelmezett és egyedi címlisták, valamint 
a megváltoztatott címzett házirend (Recipient Policy) által 
előírt címváltozások előállítására és frissítésére használja. 


Az Exchange Enterprise Servers csoport 

Az Exchange Enterprise Servers csoport tartalmazza az 
összes Exchange Domain Servers csoportot a szervezeten be- 
lül. Más szóval, minden Exchange kiszolgálóval rendelkező 
tartomány Exchange Domain Servers csoportja, amelyben a 
DomainPrep lefutott és a Recipient Update Service szolgál- 
tatás aktív, az Exchange Enterprise Servers csoport tagja. 
Ez a csoport azonnal elérhető, amint a DomainPrep a tar- 
tományának Exchange Domain Servers csoportját hozzáad- 
ta. Az összes többi, aktív Recipient Update Service szolgál- 
tatást futtató tartomány Exchange Domain Servers cso- 
portját a Recipient Update Service adja hozzá. 


Access Control Settings for Users ás -. 212 
Permissions ] Audting ] Owner] 
Permission Entjies: 
T Name T Permission —  Applyto 2 
Exchange Enterprise Servers...  Wiite Property This object and all chid 


Allow 

jvAllow Exchange Enterprise Servers...  Wite Property This object and all child 
I Allow . Exchange Enterprise Servers... . Wite Property This object and all chid 
Allow 
Allow 
Allow 












Exchange Enterprise Servers... — Wiite Property — This object and all chid 
NEZET ÁZE EKET G This object and all ohid 
Exchange Enterprise Servers... Special User objects 

Exchange Enterprise Servets Group objects 

















Ttiz permission ís inherted Írom the parent object and controls access to this object. To stop 
inherting perméssions, clear the checkbox below. You can edit the permission only at the 
barent object where ú ís defned. This permission is inherted by chid objects 


[7 Allow inheritable permissions from parent to propagate to this object 








5 Az Exchange kiszolgálók speciális jogai a felhaszná- 
lói objektumokon 


A DomainPrep futtatása előtt 

A DomainPrep futtatásához semmilyen információra nincs 
szükségünk az Exchange szervezettel kapcsolatban, még 
Exchange 5.5 telephelybe történő telepítéskor sem. 


Milyen követelményei vannak a DomainPrep futtatásának? 

A DomainPrep segédprogram futtatásához az alábbi köve- 

telményeknek kell teljesülnie: 

"8 A DomainPrep-et futtató felhasználói fióknak a 
Domain Admins csoport tagjának kell lennie 
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"B A ForestPrep segédprogramnak már le kellett futnia a 
Windows 2000 erdőben 

"0 A ForestPrep által az Active Directory számára készített 
sémamódosítások replikálásának meg kellett történnie 
a teljes szervezetben 


Mikor futtassuk a DomainPrep segédprogramot? 

A DomainPrep megfelelő működéséhez az alábbiak szükségesek: 

"0 A ForestPrep futtatása, és az összes ForestPrep módosí- 
tás teljes szervezeti replikálása után 

"0 Mielőtt az Exchange 2000 rendszergazda (amit a Fo- 
restPrep hozott létre), a tartományban telepíti az első 
Exchange 2000 kiszolgálót 

"0 Mielőtt egy felhasználói tartományban (levelező fel- 
használók vannak, de Exchange kiszolgáló nincsen) Reci- 
pient Update Service szolgáltatást szeretnénk telepíteni. 


64 és 128 Kbit/sec-os 


ACTIVE DIRECTORY 


Mikor szükségtelen a DomainPrep futtatása? 

Általában a tartomány első Exchange 2000 kiszolgálójának 
telepítése előtt futtatjuk a DomainPrep segédprogramot, de 
ez nem mindig szükséges. Abban az esetben például, ha a 
felhasználói fiók, amellyel telepítjük a tartomány első Ex- 
change 2000 kiszolgálóját azon kívül, hogy Exchange Full 
Administrator még a Domain Admins csoport tagja is, nem 
szükséges futtatni a DomainPrep-et. Ugyanez érvényes, ha 
az Exchange-et telepítő felhasználó Enterprise Admin jogo- 
sultsággal rendelkezik. 

Minkét esetben a DomainPrep az Exchange telepítésekor, 
rejtett összetevőként automatikusan lefut. 


Soós Tibor (MCSE, MCT) az Exchange Server 4.0 megjele- 
nésétől szekértője és oktatója az Exchange rendszereknek, 
az Exchange 2000 levelezőlista tanácsadója, az IOSOFT — 
John Bryce Oktatóközpont munkatársa. (soostoigjb.hu) 


sí [t vonalak 


a távközlési szol 


vbelépési díj nélkül 
vrouter biztosításával 
vwebszerver működtetésével 


Ld dt d 


v ajándék telefonos interneteléréssel 
v1 db .hu és 1 db .com domainnév regisztrácié 


VDNS szerviz biztosítással 


5) Az áraink ÁFA nélkül és 2001. április 30-ig érvényesek. 
Érdeklődjön a 06-40-HUNNET telefonszámon vagy info(dahol.com címen! 
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Hailstorm 


A probléma 


Olyan régóta szolgáljuk ki a számítógépeket, hogy szin- 
te már szükségszerűnek érezzük alárendeltségünket. Itt 
az ideje, hogy kiadjuk a jelszót: , Legyenek egyszerűbben 
használhatók a számítógépek!" Beszéljenek hozzánk, te- 
gyenek meg nekünk mindent, biztosítsák a számunkra 
szükséges információkat, segítsenek másokkal együtt 
dolgozni és alkalmazkodjanak egyedi igényeinkhez. Csak 
így tehetnek minket produktívabbá és szolgálhatnak ki 
minket teljesen, ahelyett, hogy mi szolgálnánk ki őket. 


- Michael L. Dertouzos, a MIT Laboratory for Computer 
Science igazgatója írta a The Unfinished Revolution cí- 
mű könyvében 


Az elmúlt 25 évben az informatikai technológia fejlődése hi- 
hetetlen mértékben megkönnyítette a felhasználók és vállala- 
tok munkáját, de még vannak problémák. Az egyedi alkalma- 
zások és eszközök nem veszik figyelembe más területek igé- 
nyeit. Arra kényszerülünk, hogy alkalmazkodjunk a technoló- 
giához, ahelyett, hogy a technológia alkalmazkodna hozzánk. 
Ez megnehezíti az emberek életét. Néha úgy tűnik, hogy 
minden programnak, minden webhelynek és minden eszköz- 
nek saját használati szabályai vannak. Ha például a PC-nkbe 
be akarjuk írni egy barátunk új telefonszámát, ahhoz a bil- 
lentyűzet és az egér használata kell. Ahhoz, hogy ugyanezt 
az adatot a Palm Pilot-unkba, Pocket PC-nkbe vagy a mobil- 
telefonunkba írjuk be, teljesen más rendszer használatát kell 
megtanulnunk - mintha újra kellene tanulnunk a betűket! 
Az emberek nem tudják irányítani az őket körülvevő techno- 
lógiát. A fontos és személyes adataink több száz helyen szét- 
szóródva, alkalmazásokba, termékek regisztrációs adatbázi- 
saiba, cookie-kba és webhelyek adatbázisaiba zárva tárolód- 
nak. Ha egy barátunk telefonszámát beírjuk a mobiltelefo- 
nunkba, az nem érhető el a PC email alkalmazásában: a két 
technológia képtelen az egymással való kommunikációra. 
Ha elköltözünk, az új címet minden olyan webhelyen meg kell 
adnunk, amelynek szüksége van a címünkre - ha ezt elfelejt- 
jük, az Internet "kényelmes" használata azonnal problémássá 
válik. Minden webhely egy-egy adatsziget, amely folyamato- 
san biztosítja, hogy ne legyünk képesek személyes informá- 
cióink felhasználásának irányítására. Nem tudjuk egyszerűen 
frissíteni a saját adatainkat, és nem tudjuk szabályozni, hogy 
mi történjen a megadott adatokkal - sok esetben meg sem 
tudjuk tekinteni, amit egyszer már megadtunk. 

Az alkalmazások, webhelyek és szolgáltatások elszigetelt- 
sége gyakorlatilag lehetetlenné teszi, hogy a technológiák 
együttműködjenek. Képzeljük el, hogy jegyet rendelünk egy 
online utazási helyfoglaló rendszerben, és azt szeretnénk, 
ha az útvonalterv automatikusan a naptárrendszerükhöz 
adódjon. A webhely és a naptáralkalmazás nem tud egy- 
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mással kommunikálni - de ha mégis tudnak, egyik sem tud 
semmilyen módszerrel megbizonyosodni arról, hogy vajon 
ugyanarról a személyről van-e szó. 

Mivel arra kényszerülünk, hogy mi alkalmazkodjunk a tech- 
nológiához, ahelyett, hogy az alkalmazkodna hozzánk, az 
alkalmazások, webhelyek, és az eszközök csak korlátozot- 
tan tudják kiszolgálni az igényeinket. Ez nemcsak az új 
hardver- és szoftvertechnológiák elterjedését késlelteti, de 
korlátozza a hatékony, termelékeny és hasznos termékek és 
szolgáltatások kifejlesztését is. 


Mi az a HailStorm? 

A Microsoft .NET kezdeményezés részeként a Microsoft be- 
vezeti a , HailStorm" felhasználóközpontú személyes adat- 
tár architektúrát és XML webszolgáltatás-készletet. A Hail- 
Storm lehetővé fogja tenni a jelenlegi sokezer adattároló- 
pontúak, segítségükkel a felhasználók maguk kezelhetik a 
saját adataikat. A HailStorm szolgáltatások a .NET techno- 
lógiát és architektúrát használják, amely lehetővé teszi az 
alkalmazások, eszközök és szolgáltatások együttműködé- 
sét. E szolgáltatások lehetővé teszik, hogy a felhasználók 
határozzák meg, hogy ki férhet hozzá adataikhoz, mit te- 
A HailStorm (amely a Passport felhasználói hitelesítési rend- 
szeren alapul) lehetővé teszi az alkalmazások és szolgálta- 
tások együttműködését. A HailStorm szolgáltatásokkal pél- 
dául sokkal egyszerűbbé válik az online repülőjegy-foglalás, 
mivel a felhasználó hozzájárulásával az utazási iroda szol- 
gáltatása automatikusan hozzáférhet a felhasználók beálli- 
tásaihoz és bankszámlájához. Ha üzleti ügyben utazunk és 
vállalatunk kötelező utazási irányelveket ír elő, a személyes 
tagság és a vállalat HailStorm csoportbeállításai lehetővé 
teszik, hogy az utazási szolgáltatás kínálatában automati- 
kusan csak azok a lehetőségek szerepeljenek, amelyek mind 
a személyes beállításoknak, mind a vállalati igényeknek 
megfelelnek. Miután kiválasztottuk a járatot, az utazási 
szolgáltatás (ha engedélyezzük) a HailStorm használatával 
meghatározza, hogy milyen naptárszolgáltatást használunk, 
és automatikusan ütemezi az útitervet, valamint automati- 
kusan frissíti, és értesítést küld, ha a járat késni fog. 
zal, akit meg akarunk látogatni, így ő is tudni fogja, hogy 
mikor és hova érkezünk. A HailStorm alapú naptár adatai a 
saját PC-nkkel, más PC-jével, telefonnal, PDA-val vagy bár- 
milyen más intelligens eszközzel megtekinthetők. 


Irányítás a HailStorm-mal 

A HailStorm-mal a technológia a felhasználó érdekében és 
az ő irányítása alatt működik. Hasonlítsuk ezt össze a mai 
helyzettel, amelyben nekünk kell a technológiához alkal- 
mazkodnunk, nekünk kell a híd szerepét betöltenünk a kü- 
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lönböző eszközök, alkalmazások és webhelyszínek között. A 
HailStorm-mal soha többé nem kell kézzel adatokat átmá- 
solnunk egy szolgáltatásról egy másikra. Soha többé nem 
kell amiatt aggódnunk, hogy hogyan tudjuk a címünket 
átírni minden egyes helyen, ahol megadtuk. 


A HailStorm.a személyes adatok online védelmét is 
megoldja, használatával a felhasználó kezeli a személyes 
információkat, és ő dönti el, hogy kivel és milyen felté- 
telek mellett osztja meg azokat. Az adatok tulajdonosa 
a felhasználó. Az adatok bármilyen hozzáféréséhez, mó- 
dosításához, és azok bármilyen felhasználásához a fel- 
használó kifejezett jóváhagyása szükséges. A jóváhagyás 
korlátozott hatáskörben (milyen adatok hozzáférhe- 
tők?) és korlátozott időtartamra (mikor jár le az enge- 
dély?) érvényes. A HailStorm jogi és technikai módsze- 
rekkel tiltja le az adatok jogosulatlan használatát, és ez 
a korlátozás az adott tranzakción kívül is érvényes. A 
felhasználói irányítás hangsúlyozása szöges ellentétben 
áll a jelenlegi módszerrel, amelyben az alkalmazások és 
a vállalatok birtokolnak minden olyan adatot, amelyet a 
felhasználóról nyertek, és a felhasználó megkérdezése 
nélkül, gyakorlatilag korlátlanul használhatják azt. 


A HailStorm felhasználóközpontú architektúra és szolgálta- 
táskészlet a .NET-hez, amely személyes információkat nyújt 
az Interneten egy felhasználó, egy futtatott szoftver vagy 
a felhasználó által használt eszközök számára. A HailStorm 
szolgáltatások a SOAP (Simple Object Access Protocol) és az 
XML (eXtensible Markup Language) használatával érhetők el, 
amelyek nyílt hozzáférési technológiák: minden olyan háló- 
zatra csatlakoztatott eszközről meghívhatók, amely támo- 
gatja a SOAP-ot, függetlenül attól, hogy az egy operációs 
rendszer vagy egy Internetszolgáltató. A SOAP és az XML 
nyílt Internetszabvány, amelyeket a Microsoft a .NET első 
fázisában vezetett be. A HailStorm a következő lépés. 


A HailStorm szolgáltatások 

A HailStorm szolgáltatáskészlet segít az adatok kezelésében 
és védelmében, és az alkalmazások, eszközök és szolgálta- 
tások közötti együttműködésben: 


A HailStorm architektúra 

A felhasználók a HailStorm-hoz alkalmazásaikkal, eszkö- 
zeikkel és szolgáltatásaikkal (a HailStorm végpontokkal) fér- 
nek hozzá. A HailStorm alapú eszköz vagy alkalmazás a fel- 
használó jóváhagyásával automatikusan csatlakozik a meg- 
felelő HailStorm szolgáltatáshoz. Mivel az általunk használt 
igen sok alkalmazás és eszköz egyetlen általunk kezelt, kö- 
zös információkészlethez csatlakozik, képesek leszünk biz- 
tonságosan megosztani az adatokat a különböző technoló- 
giák, valamint emberek és szolgáltatások között. 

A fejlesztők olyan alkalmazásokat és szolgáltatásokat hoz- 
hatnak létre, amelyek a HailStorm-ot használják a lehető 
legjobb eredmény elérésére. A HailStorm platform nyílt 
hozzáférési modellt használ, ami azt jelenti, hogy bármi- 
lyen eszközzel, alkalmazással és szolgáltatással elérhető, 
függetlenül a platformtól, operációs rendszertől, objektum- 
modelltől, programozási nyelvtől vagy hálózatszolgáltató- 
tól. A HailStorm szolgáltatások XML webszolgáltatások, 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 05. 


amelyek a nyílt ipari szabványú XML-en és SOAP-on alapul- 
nak; nincs szükség Microsoft környezetre vagy eszközökre a 
szolgáltatások eléréséhez. A Visual Studio.NET-ben találha- 
tó .NET infrastruktúra, a .NET Framework és a .NET Enterp- 
rise Servers természetesen teljesen támogatja a HailStorm- 
ot, hogy a fejlesztők számára a lehető legegyszerűbbé vál- 
jon a szolgáltatások használata. 

Technikai szempontból a HailStorm alapja a Microsoft Pass- 
port hitelesítés. A HailStorm architektúra olyan azonosítá- 
si, adatvédelmi és adatmodelleket határoz meg, amelyek 
közösek a HailStorm szolgáltatásokban és így konzisztens 
fejlesztést és használatot tesznek lehetővé. A HailStorm 
egy elosztott rendszer, amely különböző alkalmazásokat, 
eszközöket és szolgáltatásokat tud kiszolgálni. 

Az alapvető HailStorm szolgáltatások ezt az architektúrát 
használják a felhasználó alapadatainak (pl. a naptár, a hely- 
és profiladatok) kezelésére. A HailStorm-ot használó bármi- 
lyen megoldás használhatja ezeket az elemeket, így a fel- 
használónak nem kell újra megadnia és redundánsan tárol- 
nia az adatokat, a fejlesztőnek pedig nem kell egyedi rend- 
szert létrehoznia ezekhez. 

A HailStorm-hoz szabványos XML webszolgáltatás készlettel 
férhetünk hozzá. A HailStorm alapú megoldások XML mes- 
sage interface-k (XMI) segítségével (amelyek egyszerűen 
XML SOAP üzenetek készletei) specifikus HailStorm eszkö- 
zökkel működnek együtt. 

A HailStorm szolgáltatáskészlete a következő: 

b myAddress - elektronikus és földrajzi cím 

myProfile - név, becenév, személyes dátumok, kép 

"8 myContacts - elektronikus kapcsolatok/címtár 
myLocation - elektronikus és földrajzi hely és találkozóhely 
"8 myNotifications - értesítések kezelése és továbbítása 
mylnbox - inboxelemek (email, hangos levél) a meg- 
lévő levelezési rendszerekkel való kapcsolattartáshoz 
myCalendar - időbeosztás és feladatkezelés 
myDocuments - dokumentumtár 
myApplicationSettings - alkalmazás-beállítások 
myFavoriteWebSites - kedvenc URL-ek és egyéb web- 
azonosítók 

myWallet - számlák, fizetőeszközök, kuponok és egyéb 
tranzakciós bejegyzések 

myDevices - eszközbeállítások 

8 myServices - személyes szolgáltatások 

myUsage - a fenti szolgáltatások használatának fel- 
jegyzései 

A HailStorm architektúra konzisztens és rugalmasan bővít- 
hető. Közös adat-, üzenet-, név-, helyszín-, biztonság-, 
adatmodellezés-, mérés- és hibakezelést biztosít az összes 
HailStorm szolgáltatásban. A HailStorm olyan, mint egy di- 
namikus, partícionált, sémázott XML tár. XML message inter- 
face-ekkel (XMI) érhető el, amelyek szabványos SOAP üze- 
netek, a visszanyert értékek XML-ek, és minden szolgáltatás 
támogatja a HTTP Post-ot üzenettovábbítási protokollként. 
A HailStorm integrált adatvédelmi modellje Kerberos alapú 
hitelesítésre épül. A felhasználó szabályozza, hogy ki és mi- 
lyen céllal férhet hozzá az adataihoz. A felhasználó vissza 
is vonhatja a hozzáférés engedélyezését. A felhasználók az 
adathozzáférést egy szolgáltatás vagy agent segítségével 
kezelhetik, ezek a szolgáltatások elég egyszerűek ahhoz, 
hogy használhatók legyenek. 
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A megbízhatóság igen fontos a HailStorm szolgáltatások 
sikeréhez. A Microsoft rengeteg jó (és rossz) tapasztalatot 
szerzett Internet helyszíneinek (Hotmail web alapú email 
szolgáltatás, MSN, Microsoft.com és Passport) működtetése- 
kor, amelyek mindegyike a világ tíz legnagyobb webhelye 
között van. A Microsoft jelentős beruházásokat végez, 
hogy elérhetővé tegye azt a szolgáltatási szintet és meg- 
bízhatóságot, amit a HailStorm igényel. 


A HailStorm üzlet 

A dotcom összeomlás bizonyítja, hogy az internetes üzleti 
modellnek új alapokra van szüksége. Az ingyenes szolgál- 
tatásnyújtás nem fenntartható módszer a vállalkozások 
számára. A Microsoft .NET lehetővé teszi olyan vállalkozá- 
sok működését, amelyek az informatikát és a hálózati kap- 
csolatot felhasználva valódi értéket hozhatnak létre, olyan 
értéket, amiért az emberek hajlandóak fizetni. 

A Microsoft a HailStorm szolgáltatást üzleti alapon fogja 
működtetni. A HailStorm szolgáltatások valódi működési 
költségekkel járnak, és ahelyett, hogy a felhasználó-köz- 
pontú modellt (a kockázatosság miatt) figyelmen kívül 
hagyva valaki mással, pl. hirdetőkkel fizettetnék meg a 
költségeket, az értéket kapó emberek - a végfelhasználók 
- fognak érte fizetni. A HailStorm segítségével az Interne- 
ten a felhasználók a kapott értékkel arányosan fizetnek. 
A Microsoft a fejlesztőktől is bevételekre számít, amelyek 
segítenek a szolgáltatások és termékek költségeinek fede- 
zésében. Ezek kisebb összegek lesznek, hogy a lehető leg- 
több fejlesztő dolgozzon a HailStorm-mal, de felszámolják 
a szokásos eszköz és támogatási költséget. Valamennyit az 
éles tesztkörnyezet használatáért is fizetni kell. 

A szolgáltatáskezelők bizonyítványon alapuló licenckap- 
csolatban lesznek a Microsoft-tal, ez teszi lehetővé a 
HailStorm szolgáltatások használatát, és hogy egyetlen 
HailStorm-ot használó szolgáltatás se éljen vissza az erő- 
forrásokkal. A bizonyítvány lehetővé teszi a szabályok 
megszegőinek kiszűrését a rendszerből. A bizonyítvány be- 
szerzése és a HailStorm szolgáltatások használatának joga 
költséggel jár. A nagyobb támogatás, a szolgáltatásszintű 
szerződés és a nagyobb rendszerhasználat további költsé- 
geket jelenthet. Arra számítunk azonban, hogy ezek a költ- 
ségek lényegesen kisebbek lesznek, mint egy hasonló, füg- 
getlen szolgáltatás költségei. 

A felhasználók, fejlesztők és szolgáltatáskezelők által fize- 
tendő árak még nincsenek meghatározva. 


A fejlesztők lehetőségei 

A platform létrehozásának egyik nagy előnye, hogy lehetősé- 

get biztosít más vállalatoknak arra, hogy a platformra üzleti 

modelleket hozzanak létre. A Microsoft .NET (amelynek a 

HailStorm is része) is biztosítani fogja ezeket a lehetőségeket. 

A fejlesztők számára a HailStorm kihasználására két jelen- 

tősebb lehetőség áll rendelkezésre: 

"0 Létrehozhatnak olyan alkalmazásokat, eszközöket vagy 
szolgáltatásokat, amelyek a HailStorm szolgáltatásokat 
használják. 

0 Létrehozhatnak saját HailStorm kompatíbilis szolgálta- 
tásokat. 

Kihasználva, hogy a Microsoft jelentős beruházásokat vég- 

zett a HailStorm-ért, a fejlesztők képesek lesznek felhaszná- 
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ló-központú megoldásokat fejleszteni, hogy a technikai fel- 
tételek megteremtése helyett a saját területük fejlesztésére 
összpontosíthatnak. Ha például arról akarják értesíteni a fel- 
használót, hogy megérkezett egy áru amelyet megrendelt, a 
vállalatnak csak a SOAP és az XML létrehozásával kell törőd- 
nie, amely ahhoz szükséges, hogy kommunikálni tudjon a 
HailStorm myNotifications szolgáltatásával, amely szabvá- 
nyos SOAP és XML felülettel rendelkezik, függetlenül attól, 
hogy milyen alkalmazást használ a felhasználó. Nem kell az- 
zal foglalkozniuk, hogy létrehozzanak egy olyan rendszert, 
amely azonosítja a felhasználót, vagy értesítést küld, és nem 
kell olyan alkalmazást sem létrehozniuk, amely fogadja eze- 
ket az üzeneteket. Ehelyett arra koncentrálhatnak, hogy lét- 
rehozzák magát a szolgáltatást, amely gyorsabb, olcsóbb és 
sokkal egyszerűbben karbantartható. 

A HailStorm szolgáltatások használatával a példában sze- 
replő vállalat több embert tud elérni (mivel nincs szükség 
egyedi alkalmazástelepítésre a szolgáltatás használatához, 
mert a felhasználók már rendelkeznek a szükséges szoftve- 
rekkel) A sürgős üzeneteknek nem kell addig várakozniuk, 
amíg a felhasználó legközelebb valamilyen egyedi alkalma- 
zást használ; ehelyett az értesítést azonnal megkapja, ha 
egy HailStorm eszközt használ. Az egy megoldásba össze- 
gyűjtött szolgáltatások sokkal hatékonyabban használha- 
tók, mint az önálló megoldások. A HailStorm használatával 
az alkalmazásfejlesztők sokkal több potenciális ügyféllel 
léphetnek kapcsolatba, mint anélkül. Együttműködési al- 
kalmazás használatához nincs szükség arra, hogy mindkét 
félnél egyidejűleg nyitva legyen az alkalmazás, csak arra, 
hogy mindketten egy intelligens HailStorm eszközt hasz- 
náljanak. Ha az egyik fél egy együttműködési alkalmazás 
felhasználója, a másik pedig nem, az együttműködés így is 
létrejöhet a Passport használatával; nem kell külön alkal- 
mazás hozzá. Az alkalmazásfejlesztők számára ez azt jelen- 
ti, hogy a felhasználóik lényegesen több emberrel léphet- 
nek kapcsolatba, akik megismerik az alkalmazásaikat. 


A HailStorm elvei 


A felhasználó irányít 

A HailStorm lehetővé teszi a felhasználóknak, hogy ők ke- 
zeljék környezetüket és személyes adataikat. A többi Mic- 
rosoft szolgáltatáshoz hasonlóan a HailStorm adatvédelmi 
modellje is megfelel a személyes adatok védelmére vonat- 
kozó törvényeknek és meg fog felelni a Code of Fair Infor- 
mation Practices-nek is, ami több fogyasztóvédelmi prog- 
ram alapját fogja képezni, pl. az Online Privacy Alliance- 
ét, a TRUSTe-ét és a BBBOnLine-ét. 

A HailStorm lehetővé teszi, hogy a vállalatok olyan ajánlato- 
kat dolgozzanak ki, amelyek a felhasználó érdekében együtt- 
működve hatékony, konzisztens és testreszabott szolgáltatá- 
sokat nyújtanak. A HailStorm egyik alapvető tervezési elve az 
volt, hogy saját adatait a felhasználó kezelje. Az adatvédelem 
alapvető pontja a HailStorm architektúrának. j 

A HailStorm modell a következő információs eljárásokra épül: 
B Értesítés: a vevő értesítése az információ felhaszná- 
tásáról; 

Választás: a személyes információk figyelmes össze- 
gyűjtése és elosztása; 

"b Hozzáférés: minden személyes információhoz; 
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"0 Biztonság: A beépített védelem miatt jóváhagyás nél- 
kül senki sem férhet hozzá a személyes adatokhoz. 
A személyes adatok védelme nagyon fontos tervezési elvárás 
a HailStorm architektúrával szemben. A HailStorm adatmodell 
része egy speciális biztonsági és hozzáférési modell, amely le- 
hetővé teszi a felhasználók számára, hogy meghatározzák, 
hogy hogyan és.kivel akarják megosztani a személyes adatai- 
kat. Ez az intelligens szoftver lehetővé teszi, hogy: 
"0 Meghatározhassuk, hogy kik vagy milyen szolgáltatások 
férhessenek hozzá az adatainkhoz. 
"b Szükség szerint bárkivel megoszthassuk az adataikat. A 
HailStorm szigorú opt-in platformot alkalmaz a felhasz- 
nálói adatokhoz. 
Szükség szerint visszavonhassuk a megosztási és hozzá- 
férési jogokat. Ez az irányítási szint most általában nem 
elérhető a webhelyeken. 
"b A megosztás egy adott időre legyen érvényes: az adathoz- 
záférés rendszer által felügyelt, időhöz kötött legyen. 
A technikai lehetőségeken kívül az adatvédelemről a Micro- 
soft adatgyűjtési és használati módszerei is gondoskodnak 
a HailStorm licenccel rendelkező felhasználói számára. A 
Microsoft szerződéses úton is kiköti a használat lehetősé- 
geit, ez meghatározza, hogy mit lehet tenni a HailStorm 
forrásból származó felhasználói adatokkal. Ezenkívül a Mic- 
rosoft elektronikusan és fizikai úton is védi a HailStorm- 
ban kezelt adatokat, hogy megakadályozza a jogosulatlan 
hozzáférést és használatot. 
A Microsoft a felhasználó kifejezett hozzájárulása nélkül 
nem kezel, ad el vagy tesz közzé semmilyen HailStorm fel- 
használói adatot. A felhasználó adataival való minden köl- 
csönhatás a jóváhagyásos opt-in modell alapján megy vég- 
be: a személyes adatok csak az adat tulajdonosának kifeje- 
zett jóváhagyása esetén adhatók közre. 


Va 


Nyílt hozzáférés 

A HailStorm bármilyen olyan Internet kapcsolattal rendelkező 
eszközzel, szolgáltatással vagy alkalmazással elérhető, amely 
képes a felhasználó hitelesítésére és SOAP üzenetek küldésé- 
re és fogadására. A műveletek a platformtól, az operációs 
rendszertől, az objektummodelltől, a programozási nyelvtől, 
az alkalmazástól vagy online szolgáltatástól függetlenül szö- 
veges SOAP üzenetek formájában továbbítódnak. A HailStorm 
ügyfél- és kiszolgálóoldalról is hozzáférhető, és egyik esetben 
sincs szükség Microsoft környezetre. A Microsoft már bemu- 
tatta, hogy a HailStorm szolgáltatások Windows8-ról, Macin- 
tosh-ról, Palm-ról, Pocket PC-ről és UNIX-ról is elérhetők. 


Bővíthetőség 

A HailStorm első kiadása a felhasználók és a fejlesztők szá- 
mára feltételezhetően szükséges alapvető szolgáltatáskész- 
letet nyújtja. Ezután az új szolgáltatások (például myPhotos 
vagy myPortfolio) és bővítmények a Microsoft Open Process- 
szel a fejlesztők közösségének bevonásával vezethetők be. 
Egyetlen séma vonatkozik minden területre, hogy elkerül- 
hetők legyenek a felhasználókra káros ütközések (például, 
ha egyszerre van myTV és myFavoriteTVShows) és hogy biz- 
tosítva legyen a konzisztens architektúra például a bizton- 
sági modell és az adatkezelés esetében. A HailStorm bőví- 
téseit a Microsoft speciális szakterületenként végzi. 
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A bevezetés 

A HailStorm szolgáltatások kezdőkészlete várhatóan 2001 
végén kerül fejlesztői béta állapotba, és 2002-ben jelenik 
meg a végleges változat. A további névterek és szolgáltatá- 
sok a Microsoft Open Process során kerülhetnek online hasz- 
nálatra. A HailStorm-ra kiegészítő szolgáltatások és bővít- 
mények épülhetnek, ha az alapinfrastruktúra már működik. 


A végpontok 

A Microsoft támogatási programok segítségével jelenleg azon 
dolgozik, hogy minél több más gyártótól származó végpont 
legyen elérhető a HailStorm szolgáltatásokhoz. 

A Microsoft természetesen biztosítani kívánja, hogy minden 
Microsoft eszköz jó HailStorm végpontként működjön. Ez azt 
jelenti, hogy az összes Microsoft alkalmazás (a Microsoft Of- 
fice-tól a Microsoft játékokig) támogatni fogja a HailStorm- 
ot. A szolgáltatások (pl. a MSN és a bCentral" kisvállalati por- 
tál) HailStorm végpontként működnek, és a Microsoft szoft- 
verrel működtetett eszközök, így a Xbox" videojáték konzol, 
a Pocket PC és a , Stinger", a Microsoft intelligens telefon- 
szoftver platformja is potenciális HailStorm végpontokká vál- 
nak. A Microsoft operációs rendszerei, például a Windows XP 
és a Windows CE önmaguk is HailStorm végpontokká válnak, 
és lehetővé teszik azt is, hogy a fejlesztők egyszerűen hoz- 
hassanak létre HailStorm alapú alkalmazásokat. 

A Windows XP integrálja a Windows hitelesítési rendszert a 
Passport hitelesítési rendszerrel, így ha a felhasználó egy- 
szer belép a Windows XP-be, ezzel a Passport-ba is belép, 
így további bejelentkezés nélkül is képessé válik a Hail- 
Storm szolgáltatások használatára. A Windows XP támogat- 
ja a programozott értesítéseket, így a HailStorm myNotifi- 
cations szolgáltatás felhasználói egyszerűen megkaphatják 
a figyelmeztetéseiket a Windows XP-t futtató PC-n. 


(Úgy érzem, erre a témára még vissza kell térnünk. Az összes 
valamirevaló anyagot felhasználtuk a cikkhez, de ez így is 
igencsak szűkszavú. Miközben olvastam, az alábbi kérdések 
merültek fel bennem: 

1) Fizikailag HOL is tárolódnak akkor az adatok? Kint a 
weben? De HOL? 

2) Milyen titkosítással? 

3) Hogyan működik az időzített jogosultság? Ha én például 
egy bankkártyaszámot az engedélyezett időm alatt ki- 
másolok egy textfájlba, akkor az idő lejártával a lelop- 
tam.txt megsemmisíti önmagát? :) 

4) Lehet-e piramist építeni a Hailstormokból, hasonlóan az 
egymásra épülő Certificate Serverekhez? 

5) Ki fizet a szolgáltatásért, és mikor? Az adat tulajdonosa? 
Vagy a felhasználója? 

FM - a szerk.) 
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XML-gessünk 


(II. rész) 


Bevezetés 

Két hónappal ezelőtti számunkban elindultunk az XML-hez 
kapcsolódó technológiák felidézésével. Ebben a számban 
utánajárunk az XML dokumentumok strukturális leírására 
szolgáló sémáknak, majd rátérünk az Internet Explorer XML 
képességeire. Ezen belül elmélyedünk az XML dokumentu- 
mok formázásában az XSL és a CSS alkalmazására. Az itt 
leírt alapok megteremtik azt a tudást, amely segítségével 
már ügyfél és kiszolgáló oldalon is tudunk XML dokumen- 
tum alapú weboldalakat építeni - melynek részleteit a kö- 
vetkező számban olvashatják. 


XML Stratégia 

Az XML technológia vívmányai, akár tetszik, akár nem, a 
nyakunkon vannak, és mielőbb alkalmaznunk kell tudni 
őket. Havonta 4-5 oldalban alig lehet valamit átadni ezek- 
ből a forradalmi módszerekből, mert ha alapozással akar- 
nánk kezdeni, akkor minimum a következő 10 cikk csak fo- 
galmak tisztázásával menne el, és még mindig nem tud- 
nánk használni az XML-t, csak értenénk, hogy mit takarnak 
azok az X-szel kezdődő néhány betűs rövidítések. Emiatt a 
cikksorozatomban hibrid stratégiát vezetek be. Minden 
szám elején lesz körülbelül egy oldalnyi bevezető, amely- 
nek célja néhány fogalom tisztázása az XML háza tájáról. A 
maradék oldalakat mindig valamilyen kézzelfogható, gya- 
korlatban azonnal alkalmazható példakódokkal fogom meg- 
tölteni. A két rész nem feltétlen fog szorosan összetartoz- 
ni, de egy közös kapocs lesz közöttük: mindkettő XML-ről 
fog szólni. Emiatt előfordulhat, hogy lesz a cikkekben egy- 
két fogalom, amit előtte nem definiáltam, de ilyenkor min- 
dig hivatkozni fogok egy-egy URL-re, ahol a fogalomról 
részletes információ kapható. Vágjuk hát bele! 


Sémaleírás 

Adott az XML, mint általános, egyszerű és hatékony adatleíró 
nyelv. Önleíró, azaz egy XML dokumentumot minden külső in- 
formáció nélkül értelmezni lehet, be lehet járni a benne talál- 
ható csomópontokat, kiolvasva az elemek értékét és attribú- 
tumait. Azonban irányított kommunikáció esetén, akár gépek 
közötti információcserénél, akár gép-ember kapcsolatban sok- 
szor szabályokat kell alkotnunk a küldendő illetve fogadandó 
XML dokumentum szerkezetére vonatkozóan. Ekkor már csak 
azokat az XML dokumentumokat fogadjuk el érvényesnek, 
amelyek szerkezete megfelel a formális leírásban szereplő fel- 
tételeknek. Például egy megrendelést leíró XML dokumentum- 
ra valószínűleg kikötnénk, hogy benne kell legyen a megren- 
delő neve, címe, adószáma satöbbi. Ha a kapott megrede- 
lés.xml-ben nem szerepel minden kívánatos adat, akkor 
visszadobjuk a megrendelést, mert nem érvényes. 

Az XML dokumentum szerkezetének, más néven sémájának 
leírására több módszer is a rendelkezésünkre áll, melyek fo- 
kozatosan, a használat során fejlődtek ki. Nézzük meg mi- 


tech.net! 


lyen hárombetűs rövidítések segítenek bennünket az XML 

dokumentumok sémájának leírásában: 

"8 DTD, Document Type Definition: [1] a legelső eszköz 
volt az XML dokumentumok struktúrájának leírására. 
Több sebből is vérzik, de a legnagyobb problémája: 
nem XML formátumú. Ha már egyszer kitalálták az XML- 
t, nagyon gyors és hatékony feldolgozót (parser) írtak 
hozzá, akkor miért nem lehet az elemzendő XML doku- 
mentum sémáját is XML-ben leírni? Emellett nincsenek 
benne adattípusok, mindent csak szövegként lehet de- 
finiálni, valamint nem támogatja a névtereket, amely 
nélkül szó sem lehet több forrásból összefűzött adatok 
ellenőrzésére. Ezek igen súlyos hiányosságok, amely 
miatt a DTD hamarosan ki fog halni, de egyenlőre saj- 
nos egyedül ez az egyetlen, végleges, elfogadott séma- 
leíró nyelv. 

"I XDR, XML Data-Reduced: [2] a nagyreményű Microsoft 
DTD utód - volt. A Microsoft gyorsan lemondott a DTD 
használatáról, és gyors ütemben belekezdett egy XML 
formátumú sémaleíró nyelv kidolgozásába, amelyet a 
Word Wide Web konzorciumnak is elküldött szabványo- 
sításra. Megszületett az XDR. Amellett, hogy XML for- 
mátumú még jóval flexibilisebb is, mint a DTD. A DTD- 
ben leírt struktúrának maradéktalanul meg kell felelni 
egy XML dokumentumnak. Az XDR is tud ilyen szigorú 
lenni, de emellett elő lehet azt is írni, hogy az ellenő- 
rizendő dokumentum egyes részeiben lehetnek további 
elemek is, amelyet a séma nem ír le. Például egy sze- 
mélyről szóló XML adatlapban kötelezővé tesszük a név, 
születési dátum és az anyja neve elemeket, de ezen 
felül megengedjük, hogy egy buzgó gazdi például a ku- 
tyája nevét és haja színét is beleszerkessze a dokumen- 
tumba. A hangsúly nem azon van, hogy előírhatunk op- 
cionális elemeket, hanem azon hogy megengedhetünk 
olyan elemeket is, amelyekről a séma készítésekor még 
nem is tudtuk, hogy lesznek. Ehhez kapcsolódó szolgál- 
tatás, hogy XDR segítségével le lehet szabályozni a do- 
kumentum egy részét is, nemcsak a teljes egészet. DTD- 
vel természetesen csak az egész dokumentumra lehet 
szabályokat definiálni. 

Emellett az XDR bővíthető, azaz az igények megváltozá- 
sakor nem kell a sémát kidobni, csak egy másik névtér be- 
vezetésével kiegészíteni a meglevőt. Utolsó, de nagyon fon- 
tos szolgáltatás az XDR-ben, hogy az elemek és attribútu- 
moknak meg lehet adni a típusát (egész szám, dátum satöb- 
bi). A DTD-ben minden szövegként van deklarálva. A leg- 
több, a közeli múltban fejlesztett Microsoft termék XDR-t 
használ sémaleírásra. Azonban már a kapuban dörömböl az 

"8 XSD, XML Schema Definition [3], amely a cikk írásának 
pillanatában a leginkább aktuális sémaleíró nyelv. A 
Biztalk Server, illetve a .NET XML osztályok már tudják 
- tudni fogják ezt a sémaleírást is kezelni (természete- 
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sen az XDR mellett) . A Visual Studio 7 egyik alapszolgál- 
tatása az XSD sémák grafikus szerkesztése, konverziója 
XDR-ből XSD-be, XML dokumentumból XSD generálása 
stb. (A Visual Studio 7 illetve a .NET stratégia fejlesztői 
szemmel nézve több, mint szenzációs. Újságunkban is rö- 
videsen megkezdjük az alapok lefektetését. ) 


Az XML és a Web 

A Microsoft nagy erőkkel ráállt az XML technológiában rej- 
lő lehetőségekre, és ez az elkötelezettség meglátszik az 
utóbbi 3 év összes Microsoft termékén is. Az összes termé- 
ket áthatja az XML, legyen szó konfigurációs állományokról 
(.NET-ben minden konfigurációs adat XML fájlokban van, hel- 
lo registry — végre!) , kiszolgáló termékekről, vagy az Inter- 
net Explorer-ről. Még azt sem tudtuk mi az az XML, de az 
IE4 már támogatta, persze az akkori szabványnak megfele- 
lően még eléggé gyerekcipőben, de már működtek benne 
nagyon hasznos funkciók. A Microsoft Internet Explorer 5 
már igen hatékony XML támogatást tartalmaz, amely segít- 
ségével az információk megjelenítéshez kapcsolódó funk- 
ciók jelentős részét ügyféloldalon meg lehet oldani, csök- 
kentve ezzel a szerver terhelését. Ezt mondják Amerikában, 
ahol tényleg agyonterhelik a webkiszolgálókat a szörfözők. 
Ezzel szemben nálunk, ahol örül egy webszájt, ha van napi 
5000 találata, inkább a lassú modemes kapcsolat miatti le- 
csökkent szerverhez fordulás az, ami miatt érdemes kihasz- 
nálni az IE-ben rejlő lehetőségeket. 

Persze általában az Internetes környezetben nem köthetjük 
ki a látogatóknak, hogy használjanak IE 5.5SP1-et, mert 
csak az tudja kihasználni az általunk megírt funkciót. Azon- 
ban heterogén böngészőkörnyezetben sem kell lemondani 
az XML kínálta előnyökről, csak buta böngésző esetén az 
XML-lel kapcsolatos funkciókat a kiszolgálón kell implemen- 
tálni, és csak a kész HTML kódot leküldeni a böngészőknek. 
Okos böngészőnek megy az XML, butának a HTML. Az okos 
keveset fordul a webszerverhez, a buta sokat. 


IE és XML, a két jó barát 

Csapjunk bele az IE5 XML szolgáltatásaiba. Ha egy XML ál- 
lományt adunk meg a böngészőnek, akkor ő azt közvetlenül 
megjeleníti. 
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5 Egy közönséges XML állomány az IE5-ben [4] 
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Figyeljük meg, az c?xml version-"1.0" encoding-"ISO- 
8859-2" ?5 sort! Egyrészt leírja, hogy a dokumentum az 
XML1.0-s szabványra épül [5], valamint azt, hogy a benne 
található karaktereket az IS0-8859-2-es kódtábla alapján 
kell értelmezni. Ha ezt nem tesszük meg, az összes értelme- 
zőprogram, beleértve azt is, ami az IE mögött is van, kibo- 
rul az első ékezetes karakternél. Az IE5.5 így dohog: 


An Invalid character was found in text content. 
Line 6, Position 19 
LxCSALADP:SOczZ?SALAD2 


Jó, de ez így minden, csak nem felhasználóbarát. Alakítsuk 

át ezt HTML-é, amelyen keresztül már szépen, formázottan 

láttathatjuk az információkat. Két módszer kínálkozik erre, 
illetve egy harmadik, ami az első kettő keveréke. 

1) Írjunk egy Cascaded Style Sheet-et (CSS) [6], amiben 
leírjuk, hogy melyik elem hogyan jelenjen meg a bön- 
gészőben. Ez működő, de igen erősen behatárolt mód- 
szer, mert csak nagyon korlátozott lehetőségeink van- 
nak a cél HTML dokumentum formátumának meghatáro- 
zásában. Egyszerűen azért, mert a CSS nem erre van ki- 
találva. Arra nagyon jó, hogy leírjuk vele egy adott 
HTML elem megjelenését, de itt XML elemeket kellene 
transzformálni valamilyen, általunk definiált HTML for- 
mátumba, és erre a feladatra nem alkalmas a CSS. Vi- 
szont, erre van kitalálva az 

2) Extensible Style Language, röviden XSL [7]. Az XSL pont ar- 
ra van kitalálva, hogy tetszőlegesen bonyolult módon jele- 
nítsünk meg egy XML dokumentumot, ami nevezhetnénk 
adatforrásnak is, kihangsúlyozva, hogy az nem hordoz 
semmiféle megjelenítési információt. XSL segítségével 
könnyedén megváltoztathatjuk az adatok, elemek eredeti 
sorrendjét, megszűrhetjük a benne található adatokat, is- 
métlődéseket vihetünk be, stb. Egyszóval XSL segítségével 
olyan HTML kimenetet generálunk, amilyet csak szeret- 
nénk. Tulajdonképpen az eredeti XML dokumentumot bár- 
mi mássá is átkonvertálhatjuk vele, például egy másik XML 
dialektussá, azaz egy más struktúrájú XML dokumentum- 
má, vagy éppen szöveges állománnyá! Amivé csak akarjuk. 
Nem véletlenül fejlődött ki az XSLT [8], az XSL Transfor- 
mations szabvány az XSL-ből. Az XSL esetén a kiinduló cél 
az XML adatok meg jelenítésének szabályozása volt - alter- 
natíva a CSS mellé. Az XSLT már kifejezetten annak fényé- 
ben készült, hogy az XML dokumentumokat valamilyen 
más formátumúra akarjuk átalakítani, transzformálni. 

Van XSLT-nk, amivel pompásan át lehet alakítani a megjeleníten- 

dő XML dokumentumot HTML-é. Azonban egy bonyolultabb XSLT 

transzformáció igen áttekinthetetlen tud lenni, és ha még ebbe 
képeket, formázó parancsokat, stílusokat is beleszövünk, akkor 
egy olyan XML-HTML-formázó parancsok spagettit kapunk, ami 
karbantarthatatlan lesz. Ekkor jön a nyerő ötlet. XSLT-vel transz- 
formáljuk át a kívánatos HTML-é a forrás XML-t, és a formázások- 
ra csak hivatkozunk benne, de ne fejtsük ki őket az XSLT-ben. 

Ehelyett az összes formázó utasítást rakjuk ki CSS-be, és máris 

ötvöztük az XSLT flexibilitását a CSS szuper formázási képességei- 

vel. Mindeközben a grafikus bármikor nyugodtan átgyúrhatja a 

CSS-t, nem kell szembesülnie (és elszaladnia :) az XSLT-vel. 
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Az XSLT közbelép 

Most, hogy kipletykáltuk a grafikust, készítsünk egy XSL do- 
kumentumot, és adjuk meg a forrás XML-ünknek, hogy ami- 
kor a böngésző megjeleníti, használja az XSL-ünket. Ehhez az 
XML forrás elején megadjuk az XSL fájl elérését (na.xsl): 


c?xml version-"1.0" encoding-"ISO-8859-2"?5 
c?xml-stylesheet type-"text/xsl" href-"na.xsl"?: 
LNETACADEMIA- 


A böngésző az XML állomány betöltésekor megnézi, hogy 
van-e XSL hozzárendelve. Ha van, akkor letölti azt is, és vég- 
rehajtja az abban leírt műveleteket, majd megjeleníti a vég- 
eredményt. Nézzünk egy egyszerű transzformációt: 


c?xml version-c"1.0" encoding-"ISO-8859-2"?5 
€xsl:stylesheet xmlns:xsl-"uri:xsl"5 
€xsl:template match-"/"5 
"XCHTML2 
S,HEAD5 
€link rels"stylesheet" 
type-"text/css" href-"na.css" /5 -— (0) 
£/HEAD2 
LBODY5 
CLTABLE CLASS-"OktatokTabla"5 
LTRI 
LATD3Néve/TD2 
LKTD3Pozícióc/TD5 
cKTD:2Telefonszámc/TD5 
LxTDPEMail címc/TD5 


£/TR2 
£xs1l:for-each 


select-"NETACADEMIA/OKTATÓ: 
STR2 
£xsl:apply-templates/2 -—( 
€/TR2 
£/xs1l:for-each: 
£/TABLE2 
£/BODY2 
£/HTML2 


£/xsl:template2 


£xsl:template match-"NEV"5 -——— 5) 


SLxTDPCxsl:value-of select5"CSALAD"/5 
£xs1l:value-of select-"KERESZT"/5€/TD3 


£/xsl:template2 
£xsl:template match-"BEOSZTAS"5 


LxTDPCxsl:value-of select-—"."/5c/TD2 


£/xs1l:template2 


€xsl:template match-"TELEFON"5 ezt) 


LxTD53436 (Cxsl:value-of select-"KORZET"/5) 


£xs1l:value-of select-"SZAM"/5€/TD2 
€/xsl:templates 
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c€xsl:template match-"EMAIL"5 

LxTD2XCxsl:value-of select-"."/53c/TD2 
£/xsl:template2 


€/xsl:stylesheet2 


Hogyan hajtja vége a böngésző az imént felvázolt transz- 
formációt? A O azt jelzi, hogy a match-ben megjelölt 
elemre, ami jelen esetben a gyökér elem (cNETACADEMIA:) 
hajtsa végre a záró tagig O leírt műveleteket. Mit jelent a 
végrehajtani? A nem XSL tagokat egyszerűen bemásolja a 
kimenetbe, így egészen a 9 pontig minden bekerül a vég- 
eredménybe. Jól látható, hogy itt egy HTML táblázatot 
hoztam létre, egy fejléccel. Az XML forrásból származó tar- 
talom generálása a 8 körül történik. Az xsl:for-each arra 
utasítja az XSL értelmezőt, hogy a select után megadott 
XPath [9] kifejezés által kiválasztott elemeken menjen vé- 
gig, és mindegyikre hajtsa végre az utasítás törzsében leírt 
parancsokat. A NETACADEMIA/OKTATO XPath kifejezés az 
összes, a NETACADEMIA elem alatt létrehozott OKTATO ele- 
mekre ad egyezést, azokat választja ki (jelen esetben csak 
egyet, de ha több ismétlődő OKTATO elem lenne a forrásban, 
akkor mindegyiket). Mi történik a kiválasztott elemekkel? 
Generálódik hozzájuk egy cTR: c/TR: páros, ami HTML-ben 
a táblázat egy sorát írja le. És a lényeg, a forrásadatok a 
9 kifejezés jóvoltából kerülnek bele a kimenetbe., Az 
xsl:apply-templates elem azt jelenti, hogy az éppen feldol- 
gozás alatt álló elemre nézze meg, hogy van-e egyező sab- 
lon létrehozva. Ha van, akkor azt végrehajtja, és annak a 
kimenete beleszövődik a 0 kifejezés helyébe. Esetünkben 
a 8 paranccsal lefúrtunk az XML forrásunk cOKTATO: ele- 
méhez, így az 9-E sablonok már erről a szintről indulnak, 
azaz a match attribútumokban megadott XPath kifejezések 
kiegészülnek így: /NETACADEMIA/OKTATO/TELEFON, mond- 
juk a O sablon esetén. Másképpen fogalmazva a forrás 
XML-ben a /NETACADEMIA/OKTATO/TELEFON elérési úttal 
jelzett elem elérésekor az XSL processzor meghívja a O 
sablont. A sablonon belül az xsl:value-of elem kiválasztja 
a select-"KORZET" által kijelölt elem értékét, azaz a 
2KORZET5c/KORZET: közötti szöveget 9. Néhány egyéb 
formázó karakter és a SZAM elem értékének felolvasása 
után a sablon véget ér. Ezután az XSL motor megnézi, 
hogy van-e még más sablon, ami egyezést mutat valame- 
lyik elemmel. Esetünkben mind a négy sablon szóhoz jut 
minden egyes oktatóhoz. 

Miután 8 végigment az összes elemen, kiíródik a táblázat 
vége, és véget ér a végrehajtás a 0 ponton. 

Aki ezt az utat lelkiismeretesen végigkövette, az megér- 
demli, hogy megnézze a végeredményt: 
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Mitől lett ez ilyen díszes és tarka (mi lesz ebből a szürke 
újságban?! :) ? Hát attól, hogy az XSL által generált HTML 
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kimenet kapott még egy CSS-t is a O-val megjelölt sorban. 
Anélkül csak egy fehér táblázatot látnánk. A teljesség ked- 
véért itt az na.css tartalma: 


SLxKSTYLE2 

BODY 

1 
BACKGROUND-COLOR: snow 

§ 

TABLE.OktatokTabla 

( 
BORDER-RIGHT: groove; 
BORDER-TOP: groove; 
BORDER-LEFT: groove; 
COLOR: mediumblue; 
BORDER-BOTTOM: groove; 
FONT-FAMILY: Tahoma; 
BACKGROUND-COLOR: lightgoldenrodyellow 

§ 

TD 

( 
BORDER-RIGHT: thin groove; 
BORDER-TOP: thin groove; 
BORDER-LEFT: thin groove; 
BORDER-BOTTOM: thin groove 

) 

£/STYLEZ; 


Az előbbi XSL transzformáció egy nagyon egyszerű példa volt, 
ennek ellenére már ez is elég átláthatatlan és bonyolult lett. Az 
XML technológia bonyodalmaiba akkor kóstolunk bele igazán, 
amikor az XSLT nyelvet kezdjük el használni. A gond az, hogy 
az XSLT nem procedurális nyelv, hanem alapvetően sablonok 
egyeztetésén alapul. Ez a fajta gondolkodás igen szokatlan egy 
Basic vagy C nyelven felnőtt programozónak. 

További nehézség, hogy mit tehetünk akkor, ha egy jó bo- 
nyolult XSLT transzformáció nem úgy működik, ahogy azt el- 
várjuk tőle? Nem formátumbeli hibákra gondolok, azt kiszű- 
rik a transzformáló komponensek. Akkor leszünk meleg hely- 
zetben, ha , csak" logikai hiba van az XSLT-nk működésében, 
és nem azt a transzformációt hajtja végre, amit mi módol- 
tunk ki. Ilyenkor jönnek képbe a nyomkövető vagy debugger 
programok, amelyek segítségével lépésenként lehet végre- 
hajtani a programunkat, ebben az esetben az XSL transzfor- 
mációt. Ez egy kemény feladat, de szerencsére az Activesta- 
te cégnek - amely elsősorban a Win32-es Perl eszközeiről hí- 
res - megjelent a Visual XSLT 1.0 [10] programja, ami egy 
plug-in a Visual Studio.NET 7-hez, és amelynek segítségével 
szerkeszthetjük és nyomkövethetjük az XSL transzformá- 
cióinkat. Szenzációs termék! A debugger ablakban láthatjuk 
a transzformáló XSLT-t, benne az éppen végrehajtás alatt ál- 
ló XSL paranccsal. A Watch ablakban láthatjuk a forrás XML 
éppen feldolgozás alatt álló elemeit, az Output window-ban 
pedig a transzformált végeredményt. 

A program jelenleg Beta 1 állapotban van, hasonlóan a Vi- 
sual Studio.NET 7-hez. Ennek ellenére aki komolyan, a jelen- 
ben és a jövőben élve szeretne XML-lel foglalkozni, minden- 
képpen szerezzen be egy példányt a Visual Studio.NET 7-ből, 
és töltse le a Visual XSLT 1.0-t. Mindkettő Must Have! 
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Újdonságok 

Az XML-t alkalmazó alkalmazásokat programozók legalapve- 
tőbb fegyvere a parser, XML értelmező, amely az XML Docu- 
ment Object Model-en keresztül programozottan elérhetővé 
teszi az XML dokumentumok belső szerkezetét. A parser-ek 
lehetővé teszik a felolvasandó XML dokumentumok ellenőr- 
zését egy megadott sémával szemben, amely jelen pillanat- 
ban - Microsoft-os platformon - DTD és XDR-el történhet. 
Az aktuális parser a Microsoft-tól a 3-as verziónál jár, ez az, 
amit éles környezetben is lehet használni. 

Azonban nincs megállás. Áprilisban a Microsoft kiadta a Mic- 
rosoft XML Parser (MSXML) 4.0 Technology Preview Release-t. 
Ezt még nem ajánlják produkciós környezetbe, de mindenkép- 
pen érdemes tanulmányozni. Miért? Azért, mert végre támo- 
gatja az XSD-t! A parser-ben implementált séma validáló kód 
a Wide Web Consortium (W3C) XML Schema, 2001. március 
30-ikai ajánlásában leírt módon működik, azaz olyan friss, 
hogy még meleg! Mivel ez még mindig nem a végleges XSD 
szabvány, így várható, hogy az valamennyit még változni fog 
a végleges kiadásig. Az XML parser 4 természetesen követni 
fogja a változásokat, újabb és újabb kiadásokkal. 

Mi van még a csomagban az XSD mellett? Megjelent benne 
egy új objektum, az MXHTMLWriter, amely segítségével a SAX 
API által felolvasott XML dokumentumból kapott adatfolya- 
mot lehet HTML-lé transzformálni. Ez egy alternatív megoldás 
lesz az XML --s XML DOM --s XSLT --s HTML feldolgozásra, ki- 
fejezetten nagyteljesítnményű webalkalmazásokhoz. 

Az új verziót fel lehet telepíteni olyan gépre is, amin már 
van MSXML3-as parser, így az alkalmazáaok a verzió függő 
ProgID-k használatával tudják használni mind a 3-as, mind 
a 4-es változatot. Arra viszont vigyázzunk, hogy ne rakjuk 
fel produkciós szerverre, mert a verziófüggetlen objektum- 
létrehozást alkalmazó programok az új verzióból fognak egy 
példányt kapni, ami meglepetéseket okozhat. 


Zárszó 

Aki lelkiismeretesen végiglépkedett a példa XSL-en és XML-en, 
annak már van fogalma az XML alapú fejlesztések alapköveiről, 
látja a jéghegy csúcsát. De az igazi csemege még a víz alatt 
van. A következő számban a transzformációt már nem fogjuk az 
Internet Explorer-re bízni, hanem a kezünkbe vesszük az XML 
DOM-ot, és azzal hajttatjuk végre az XSL-ünket, mind kiszolgá- 
ló oldalon, mind ügyfél oldalon. És ha már ott vannak az ada- 
tok a böngészőben, miért ne lehetne rögtön szűrni illetve sor- 
barendezni őket, anélkül, hogy a szerverhez kellene fordulni.? 
Miért is ne? A júniusi számban megmutatom hogyan. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo (2onetacademia.net 


A cikkben szereplő URL-ek: 


[1]: DTD szabvány http://www.oasis-open.org/cover 

[2]: XDR szabvány http://www.ltg.ed.ac.uk/-ht/XMLData-Reduced.htm 
[3]: XSD http://www.w3.org/XML/Schema 

[4]: Példakódok http://technet.netacademia.net/feladatok/xml 


[5]: XML1.0 szabvány, magyarázattal! http://www.xml.com/axml/testaxml.htm 


[6]: CSS szabvány http://www.w3.org/Style/CSS 

[7]: XSL szabvány http://www.w3.org/Style/XSL 

[8]: XSLT szabvány http://www.w3.org/TR/xslt 

[9]: XPath szabvány http://www.w3.org/TR/xpath 

[10]: Visual XSLT 1.0 Beta 1 
http://www.activestate.com/ASPN/Downloads/VisualXSLT 
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Transact SOL 


(VII. rész) 


Az árvíztűrő tükörfúrógép 


Bevezetés 

Egy hónap kihagyás után újra itt a Transact SOL sorozat, töret- 
len lendülettel! E havi részünkben azokkal a nyelvi finomságok- 
kal és SOL Server 2000 újdonságokkal foglalkozom, amelyek 
nem kaptak akkora hírverést mint mondjuk az XML támogatás, 
de nagyon fontos apróságok, amelyek különösen magyar nyel- 
vű szövegeket kezelő programok írásakor nagyon fontosak. Jár- 
junk utána az ő ű betűk misztériumának! 


Az alapprobléma 

Ki ne bosszankodott volna azon, hogy egy lementett (bac- 
kup), magyar nyelvi beállításokkal működő adatbázist nem 
lehetett visszaállítani egy angol nyelvi beállításokkal tele- 
pített másik SOL Server 7-re, a nyelvi beállítások különbö- 
zősége miatt? Ennek az az egyszerű oka volt, hogy az SOL 
Server 7-ben a nyelvi beállítás globális, kiszolgálószintű 
volt, amely az összes adatbázisra, és azon belül az összes 
objektumra, adatra, oszlopra vonatkozott. Ez az információ 
benne volt a felhasználói adatbázisokban is, így visszaállí- 
táskor az SOL Server 7 észrevette a nyelvütközést, és nem 
engedte a visszaállítást. 

De miért van egyáltalán szükség az egész nyelvi hókusz- 
pókuszra? Miért volt ez annyira beleépülve a kiszolgálóba? 
A probléma alapja a nemzetek nyelveinek különbözőségé- 
ben keresendő. 

Ha egy karaktert egy bájton ábrázolunk, akkor 256 féle ka- 
raktert tudunk leírni. Ez bőven elég az angol abc leírásá- 
hoz, még sok egyéb extra karakter (-/99...) is belefér. 
Azonban a bőségből gyorsan ,szűkség" lesz, ha elkezdjük 
felmérni és megpróbáljuk ábrázolni az összes nemzet vala- 
mennyi karakterét. 256 hely erre nem elég. Ezt feloldandó 
minden ország, helyesebben minden országcsoport, amely- 
nek azonos karaktereik vannak az abc-ben kap egy karakter 
kódtáblát, kódlapot (character set), ami az ő nyelveikben 
található betűket rendeli hozzá a 0...255-ös tartományhoz. 
A nem ékezetes betűk általában ugyanarra a kódra vannak 
leképezve a legtöbb kódlapban, így például a kis ,a" betű 
a 97. pozícióra. Ellenőrzés: 


-- Nyelvi beállítás: Latinl General 
-- (nyugati nyelvek) 

SELECT ASCII("a") 

97 


Az ékezetes betűk helye már legtöbbször nyelvfüggő. Bizo- 
nyára mindenkinek ismerős a magyar ,ő" és az ,ű" betűk 
problémája. Ha egy számítógépen a nyelvi beállítások nem 
megfelelőek, akkor mindig ezzel a két karakterrel szokott 
baj lenni. Nézzünk csak ennek a körmére! Latin 1 (nyugati 
nyelvek) kódkészletet használva kérdezzük le az ,ő" betű 
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kódját, azaz azt, hogy ez a betű a Latin 1-es kódlap melyik 


--Adatbázis beállítás: Latinl General 
SELECT ASCII("ő") 
111 


Ez egy picit gyanús, mert az ékezetes betűk általában a 128 
feletti pozíción foglalnak helyet. Tegyünk egy ellenpróbát, 
az így kapott karakterkódot alakítassuk vissza az adott kód- 
lapon érvényes karakterré: 


SELECT CHAR(ASCII("ő")) 


o 111 


Hoppá, a kis , ő" betűnkből , o" lett! Nem véletlenül volt 
gyanús a 111-es kód. Az valójában az , 0" betű kódja: 


SELECT ASCII("o!) 
111 


Mi volt itt a gond? Az, hogy a Latin1-es kódlapban, nincs 


helye a mi , ő" betűnknek! Nézzük csak meg milyen karak- 
tereket ismer a Latin1: 


DECLARE €i int 

DECLARE €s varchar(2000) 
SET és s !"" 

SET gi 5 32 

WHILE €i c 256 


BEGIN 
SET és - és 4 CHAR(€i) 
SET €i s Git1 


--Sortörés minden 32. karakter után 
IF €i $ 32 5 0 SET és - €s 4$ CHAR(13) 
END 


PRINT és 


A lekérdezés kimenetét a nyomdai utómunkák okozta lehet- 
séges karakter konverziók, torzulások miatt grafikusan mu- 
tatom meg. Hiába, a karakterkonverzió nem csak az SOL 
Serverben problémás pont. :-) 
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o Karakterek a Latin1 kódlapban. Hová lettek az ő ű 
betűink? 

Jól látható, hogy kétvesszős , ő" nincs ebben a készletben, 
csak kalapos, meg hullámos tetejű. Azaz, ha szeretnénk 
használni normális magyar karaktereket, akkor át kell kap- 
csolnunk az adatbázisunkat egy olyan kódkészletre, amely 
ismeri a rendes betűinket. Praktikusan magyarra. Lássuk, 
ekkor jól működnek-e a konverziók: 


--Átkapcsolunk magyarra 
ALTER DATABASE LangTest 
COLLATE Hungarian CI AI 
--Teszt 1: karakterből ASCII kód 
SELECT ASCII("ő") 

245 
--Teszt 2: a kapott ASCII kódból karakter 
SELECT CHAR(ASCII("ő")) 

ő 


Remekül megy! Azaz leszögezhetjük, hogy a magyar karak- 
terek sikeres kezeléséhez vezető út első lépése a megfelelő 
karakterkészlet beállítása az adatbázisra. 

Az összehasonlítás kedvéért nézzük még meg a magyar 
kódkészletet is: 
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0 Karakterek a magyar kódlapban. Itt már a helyükön 
vannak az ékezetes betűink. 


Amikor két számítógép, vagy két adatbázis között mozgatunk 
nem UNICODE szöveges adatokat, akkor a célhelyen kódkon- 
verzió történik. Ez a konverzió a célgép operációs rendszeré- 
nek kódtábláiban van definiálva. Abban az esetben, ha a for- 
rásszövegben van olyan karakter, ami a célszerver (adatbázis) 
kódtáblájában nincs definiálva, a konverzió sokszor az adatok 
megváltozásával jár. Ennek tipikus megjelenése, amikor egy 
adatbázis ügyfélalkalmazás nem jeleníti meg az ,őű" betűket, 
hanem ,ou"-t ír ki helyette. Például a képen látható Enterpri- 
se Manager ablakban megjelenítettem egy tábla tartalmát, 
amelyben helyesen, magyar kódlappal vannak eltárolva a ka- 
rakterek. Csakhogy az Enterprise Managert futtató Windows 
2000 System Local-je English-re volt állítva, így az ügyféladat- 
bázis meghajtóprogramja átfordítja a kiszolgálóról letöltődő 
karaktereket angol kódlapra - megkérdőjelezhető sikerrel: 


Kea Sin N E enne ár old 
lelzEBmelmi! kylgax)] 













árvízturo tükörfúrógép ÁRVÍZTURO TÜKÖRFURÖGÉP 


60 Hová lettek az őű betűűűűk? 


Ha a System Local-t magyarra állítom, akkor mindjárt jól 
működnek az ékezetes karakterek is: 






e ]éb aba 











árvíztűrő tükörfúrógép ÁRVÍZTURŐ TÜKÖRFÜRÖGÉP 


a Ügyfél Windows 2000 System Locale: magyar. Megjöt- 
tek az őű betűk. 
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Nem állítom, hogy át kell állítani mind az SOL Server mind az 
ügyfél munkaállomások System Local-jét magyarra ahhoz, hogy 
ne történjék adatvesztés a konverzió során, de ha más ellenérv 
nem szól ellene, akkor érdemes ily módon beállítani őket. Ez 
nem feltétlenül szükséges, viszont elégséges feltétele a fájdalom- 
mentes, magyar szövegekkel operáló adatbázisműveleteknek. 


Adatbázis collation 

Lehet, hogy már sikerült meggyőzni a cégvezetést, és min- 
den gépen magyar beállításokkal működik az NT vagy a 
Windows 2000. Biztos lehetek benne, hogy ezek után min- 
den rendben lesz az ékezetekkel? Természetesen - nem! Az 
SOL Server 2000-ben adatbázisonként is megadható a 
nyelvi beállítás, így előfordulhat, hogy mégis gond lesz az 
adatmozgatások során. Nézzünk egy példát, ami jobban 
megvilágítja a jelenséget! Hozzunk létre két adatbázist, az 
egyiket állítsuk magyar collation-űre, a másikat Latin1-re. 
Szúrjuk be a cikk címében szereplő tesztszöveget a ma- 
gyarra állított adatbázis egy táblájába, majd egy közönsé- 
ges INSERT ... SELECT párossal másoljuk át a magyarba be- 
szúrt sort az angol adatbázis táblájába. Figyeljük meg, mi- 
kor történik konverzió, és mikor nem! A példában a System 
Local magyar mind a kiszolgálón, mind a munkaállomáson 
(egy gépen vannak :), tehát az nem okozhat problémát. 


USE master 
--Angol (Latinl) COLLATION-ű adatbázis létrehozá- 
sa 
CREATE DATABASE LangTestEng 
ON 
( 
NAME- " LangTestEngPrimary " , 
FILENAME- " c: Itempilangtesteng.mdf " 
) COLLATE Latinl General CI AS 


--Magyar COLLATION-ű adatbázis létrehozása 
CREATE DATABASE LangTestHun 
ON 


( 
NAME- " LangTestHunPrimary " , 
FILENAME- "c: Itempllangtesthun.mdf" 
) COLLATE Hungarian CI AS 


--Teszttáblák létrehozása mindkét adatbázisban 
USE LangTestHun 


CREATE TABLE Dumak ( 


Szoveg varchar(50) ) 
USE LangTestEng 


CREATE TABLE Dumak ( 


Szoveg varchar(50) ) 
USE LangTestHun 
--Beszúrás a "magyar" adatbázis táblájába 
INSERT Dumak (Szoveg) VALUES ( 
"1. árvíztűrő tükörfúrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" 
) 
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--Jól sikerült? 


SELECT Szoveg FROM Dumak 
Kimenet: 


Szoveg 


1. árvíztűrő tükörfúrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP 


Azaz a magyar beállításokkal rendelkező táblába sikerült 
helyesen beszúrni a szöveget. Mehet a másolás. 


--Másoljuk át a magyarba beszúrt sort 


--az angol collation-ű adatbázisba. 


INSERT LangTestEng..Dumak SELECT Szoveg FROM Dumak 


--Ellenőrizzük le, mi jelent meg benne! 


SELECT Szoveg FROM LangTestEng..Dumak 


Az másolatban bizony leestek a kedvenc kétvesszős magyar 
karaktereink: 


Szoveg 





1. árvízturo tükörfúrógép ÁRVÍZTURO TÜKÖRFÚRÓGÉP 


Hasonlóan kiábrándító az eredmény, ha közvetlenül az an- 
gol nyelvű adatbázis táblájába próbálunk adatokat csem- 
pészni: 


USE LangTestEng 


-- Beszúrás közvetlenül az angol 

-- adatbázis táblájába 

INSERT Dumak (Szoveg) VALUES ("2. árvíztűrő tükör- 
fúűrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP") 


--Jól sikerült? 
SELECT Szoveg FROM Dumak 


Kimenet: 


Szoveg 
1. árvízturo tükörfúrógép ÁRVÍZTURO TÜKÖRFÚRÓGÉP 
2. árvízturo tükörfúrógép ÁRVÍZTURO TÜKÖRFŰRÓGÉP 


Oszlop collation 

Ha létrehozunk egy táblát egy adatbázisban, akkor annak 
a szöveges oszlopai öröklik a szülő adatbázis collation-jét. 
Ha ez nekünk nem megfelelő, akkor a tábla létrehozásakor 
akár oszloponként megadhatunk különböző collation-öket. 
Így előállhat az a helyzet, hogy egy angol collation-ű 
adatbázisban létrehozunk egy magyar nyelvű oszloppal fel- 
vértezett táblát. Például: 
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USE LangTestEng 


CREATE TABLE Dumak ( 


Szoveg varchar(50) COLLATE Hungarian CI AS ) 


Ha a korábbi példában látott módon a magyarból másolunk 
az angolba, akkor most helyesen fognak átmenni az ékeze- 
tek, mert a céloszlop collation-je megegyezik a forráséval, 
így nincs szükség konverzióra. 

Ami viszont nagyon érdekes, hogy a közvetlenül az angol 
nyelvű adatbázisba beszúrt adatokról elvesznek az ékeze- 
tek, annak ellenére, hogy a céloszlop magyar nyelvű: 


USE LangTestEng 
INSERT Dumak (Szoveg) VALUES ("3. árvíztűrő tükör- 
fűrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" ) 


SELECT Szoveg FROM Dumak 
Szoveg 


3. árvízturo tükörfúrógép ÁRVÍZTURO TÜKÖRFŰRÓGÉP 


Ez még ügyféloldalon konvertálódik át ,éktelenné", ami 
megelőzhető, ha a tesztszövegünket megjelöljük (N a szö- 
veg előtt), hogy az UNICODE formátumú, így az konverzió 
nélkül át tud utazni a kiszolgálóra. Igaz, hogy ott vissza 
kell konvertálni egybájtossá, de azt már az SOL Server he- 
lyesen, az oszlop típusának megfelelően teszi meg. Azaz: 


USE LangTestEng 


--Beszúrás közvetlenül az angol 
-- adatbázis táblájába 
INSERT Dumak (Szoveg) VALUES (N"3. árvíztűrő tükör- 


fúrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP " ) 
SELECT Szoveg FROM Dumak 


Szoveg 


3. árvíztűrő tükörfűrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP 


Láthatjuk, hogy sok apró finomság állhat az ékezetek útjá- 
ba. Mit tehetünk a siker érdekében? Ha van lehetőségünk 
homogén SOL Server-farm kialakítására, és nem szeretnénk 
csak magyar nyelvet, esetleg angolt (részhalmaza a magyar 
kódlapnak, általában nincs vele probléma) használni a táb- 
lákban, akkor állítsuk be mind az NT, 2000 kiszolgálókat, 
mind az SOL Servereket magyarra, és hagyjuk, hogy az adat- 
bázisok és az oszlopok örököljék a magyar beállításokat. Ez 
különösen hálás lesz akkor, ha adatokat kell replikálni a 
szerverek között. A replikáció nem szereti a vegyesen beál- 
lított collation-öket, úgyhogy megéri még az elején kon- 
szolidálni a kiszolgálóparkot. 


UNICODE, az univerzális megoldás? 

Most mondhatná valaki, hogy miért kell ennyit problémázni a 
nemzeti karaktereken, amikor már ezer éve kitalálták a UNI- 
CODE-ot? Valóban, a UNICODE arról szól, hogy ne egy, hanem 
két byte-on írjuk le a karaktereket, így az eredő 65536-os tar- 
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tományba majd csak belefér minden ország összes karaktere. 
Ez így igaz. Azonban nagy tömegű adathalmaznál ennek ára 
van - a kétszeres helyfoglalás. 100 MByte-nál ez nem kérdés, 
de pár tíz GByte felett ez már nagyon is számít. 

Emellett a UNICODE túl nagyágyú, ha tudjuk, hogy soha nem 
fogunk ugyanabban az oszlopban többféle nyelvű szövegeket 
tárolni. Amennyiben ez a feladat, gondolkodás nélkül az UNI- 
CODE-hoz kell nyúlni. Egyes ázsiai nyelveknek több ezer ka- 
rakteres betűkészlete van, ezeket csak UNICODE karakterekkel 
lehet leírni - ebbe is ritkán fut bele magyar ember. Ha SOL 
Serverek között mozgatunk adatokat, és nem azonos kódlapo- 
kat használnak a kommunikáló felek, akkor is érdemes UNICO- 
DE-ot használni, így várhatóan nem lesz gond a karakterek át- 
vitelével, mert nincs szükség kódfordításra. 

Azaz, ha teljesen biztosra akarunk menni, és kiszolgáló-, il- 
letve adatbázisbeállítástól független módon akarunk ma- 
gyar esetleg más nyelvű szövegeket tárolni, akkor használ- 
junk UNICODE karaktereket: 


USE LangTestEng 


CREATE TABLE DumakUNI ( 


Szoveg nvarchar(50) ) 


Ekkor nincs szükség karakterkonverzióra, hisz UNICODE ese- 
tén nincs szükség kódlapokra, a 65536-os tartományban jól 
megférnek egymás mellett a nemzetek karakterei. Egyre fi- 
gyeljünk nagyon, használjuk az N prefixet a konstans szö- 
vegek előtt, jelezve, hogy UNICODE adatról van szó. Így egy 
angol nyelvű oszlopba, egy német alapértelmezett nyelvű 
kiszolgálón is hibátlanul át fognak menni a magyar ékeze- 
tes karakterek (is). 

Mindezen előnyök ellenére, ha nincs kényszerítő okunk a 
UNICODE használatára, érdemes maradni az egybájtos típu- 
soknál, megfelelő kódlap kiválasztásával. Ez persze vitatha- 
tó pont, ez csak az én személyes álláspontom. 


Collation - részleteiben 

Mit takar az az immáron többször is felbukkanó homályos fo- 
galom, hogy nyelvi beállítás, vagy collation? Alapvetően a 
szöveges információk tárolását, leképezését (kódlap), sorba- 
rendezését és a karakterek viselkedését az összehasonlítások 
során határozza meg. Járjuk ezt egy kicsit körbe! 

Kezdjük az összehasonlításokkal. , Alma" - , alma"? Ha Case In- 
sensitive módon hasonlítjuk őket össze, akkor egyformának te- 
kinthetjük őket, azaz a kis-nagybetű különbségeket nem 
vesszük figyelembe. Ha a beállítás Case Sensitive, akkor termé- 
szetesen a kettő nem egyezik meg. Ez eddig nem volt nehéz. 
Amit már sokkal kevesebben ismernek, az az Accent Sensi- 
tivity fogalma. Ez azt jelenti, hogy két szöveg, amelyek 
csak ékezetben különböznek egymástól egyformának te- 
kinthető-e? Például ,Eger" — ,Egér"? Ha a nyelvi beállítás 
Accent Insensitive, akkor igen. Ha Accent Sensitive, akkor 
különböznek egymástól. Mi magyarok, akik ékezetes betűk- 
kel írunk általában megkülönböztetjük az ékezetes betűket 
éktelen társaiktól. 

Japán nyelvet kedvelőknek: ha az adott collation Kana-sen- 
sitive, akkor a Hiragana és Katakana karaktereket megkülön- 
bözteti a kiszolgáló. Hurrá! Ez nagyon hasznos szolgáltatás a 
Japánoknak - na de miért kell ezzel nekünk törődnünk? 
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Azok, akik próbáltak már visszaállítani SOL Server 7-es 
adatbázist, tudják, hogy érdemes tudni a szerver Kana ér- 
zékenységének a beállított értékét, még akkor is, ha az a 
magyar nyelvre nem releváns. Ugyanis egy 7-es adatbázis- 
ban benne van az összes nyelvi beállítás aktuális értéke, 
beleértve a Kana-t is, valamint még egyet, amiről nem be- 
széltem, a Width érzékenységet is. Mit tennénk abban az 
esetben, ha kapunk egy SOL Server 7-es backup-ot, és azt 
mondják, hogy telepítsünk egy új SOL Servert, és állítsuk 
vissza rá a mentést? Ha tudjuk a Server eredeti nyelvi beál- 
lításait, beleérve kanna és vid pajtásokat is, akkor egysze- 
rűen feltelepítjük a szervert, és visszaállítjuk a kért adat- 
bázist. Viszont, ha nem, akkor maximum 16 féleképpen 
(Case, Accent, Kana, Width kombinációi) kell feltelepíteni, 
és amelyikre visszatöltődik az adatbázis, úgy volt beállítva 
az eredeti korábban. A rebuildm.exe meggyorsíthatja ezt a 
folyamatot, amivel az SOL Server teljes újratelepítése nél- 
kül át tudjuk változtatni az alapértelmezett nyelvi beállí- 
tásokat, de még így is elég gyilkos móka a restore. 


Tipp: ha van a közelben egy SOL Server 2000, akkor 
arra probléma nélkül vissza lehet tölteni az SOL 7-es 
adatbázist, és meg lehet nézni az nyelvi beállítását. 


Azaz látjuk, hogy SOL Server 7 esetén telepítéskor meg kellett 
adni a karakterkészletet, ami ,beleégett" a szerverbe, és attól 
kezdve csakis azzal a kódkészlettel tudott dolgozni. Ez azt je- 
lentette, hogy onnantól kezdve az összes, nem UNICODE osz- 
lop a megadott kódlappal, az operátorok és sorbarendezések 
pedig a beállított nyelv logikája szerint működtek. Ha más 
nyelv kellett, újra kellett építeni a master adatbázist, ami ha- 
tásaiban egy SOL Server újratelepítéssel egyenértékű. 

SOL Server 2000 esetén három szinten jelennek meg a nyelvi 
beállítások: szerverre alapértelmezetten, adatbázisszinten és a 
táblákban oszlopszinten. A Server alapértelmezett beállítása 
lesz érvényes az összes rendszeradatbázisra is: master, model, 
tempdb, msdb, és distribution. Ezt csak a telepítés folyamán 
lehet megadni, később már csak újratelepítéssel cserélhető le 
másra. Ez kihat az összes objektum nevének és egyéb tulaj- 
donságának a kezelésére is. Így az oszlopnevekre is, amiből 
mókás hibák adódhatnak. Például tegyük fel, hogy a nyelvi 
beállítás Case Insensitive, és magyar. Legyen egy oszlop neve 
cString. Ekkor miért ne hivatkozhatnánk (mondjuk egy script- 
ben) az oszlopra, mint cstring, hisz kis-nagybetű nem számít? 
Hivatkozhatunk, de ekkor jön a hibaüzenet, hogy nem ismer 
ilyen oszlopot. Miért? Mert ,cs" egyenlő csé, míg cS egyenlő 
cées - legalábbis a magyar nyelvben. És a kiszolgálóban az 
összehasonlítások is átalakultak magyarrá. . . 

Ezek a tulajdonságok nagyon úgy hangzottak, mint az SOL Ser- 
ver 7-nél megismertek. Mi a különbség? Amikor létrehozunk 
egy új adatbázist, akkor az a model adatbázis másolataként 
jön létre, azaz indirekt módon örökölni fogja azokat a nyelvi 
beállításokat, amelyeket a szerverpéldányra adtunk meg (ha- 
csak nem módosítottuk a model-t) . Viszont ettől - ellentétben 
a 7-es verzióval - eltérhetünk az adatbázis létrehozásakor, a 
COLLATE kulcsszó használatával. Azaz a globális beállításoktól 
függetlenül megadhatunk olyan nyelvet, amely alatt szeret- 
nénk működtetni az adatbázisunkat. 
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Beállítási lehetőségek 

A következőkben a LangTest nevű adatbázison keresztül 
bemutatom a különböző nyelvi beállítási lehetőségeket az 
SOL Server 2000-ben. 

Az SOL Server példány alapértelmezett nyelvi beállításának 
lekérdezése: 


SELECT SERVERPROPERTY ("Collation") 
SOL Hungarian CP1l250 CI AS 


Az adatbázis nyelvi beállításának lekérdezése: 


SELECT 
DATABASEPROPERTYEX ( LangTest", "Collation") 


SOL Hungarian CP1250 CI AS 


Az adatbázis nyelvi beállításának megadása vagy megvál- 
toztatása: 


CREATE illetve ALTER DATABASE LangTest 
COLLATE Hungarian CI AI 


Tábla létrehozása, többféle nyelvű oszloppal: 


CREATE TABLE VegyesDuma 

( 
AngolSzoveg varchar(500) 
COLLATE Latinl General CI AS, 
MagyarSzoveg varchar(500) 
COLLATE Hungarian CI AS, 
NemetSzoveg varchar(500) 
COLLATE German PhoneBook CI AS, 
--Ez olyan collation-ű lesz, mint az adatbázis 


DBDefaultSzoveg varchar(500) 


A lehetséges nyelvi konstansok listája: 


SELECT $t FROM ::fn helpcollations() 


name description 
Hindi CS AS KS WS Hindi, case-sensitive, accent... 


Hungarian BIN Hungarian, binary sort 


Csak a magyarok altípusai: 
SELECT name FROM ::fn helpcollations() 
WHERE name LIKE "Hungarian$" 


Hungarian BIN 
Hungarian CI AI 
Hungarian CI AI WS 


Hungarian CI AI KS 


Egy kis magyarázat a fenti konstansokhoz. Az első rész a 
nyelvet vagy nyelvcsaládot jelenti. Utána a Case Sensiti- 
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vity jelzése (S-Sensítive, I-Insensitive). Az ,A" mint Ac- 
cent, teljesen hasonlóan. A K és a W pedig a Kana ill. Width 
érzékenységet jelöli. Azaz, ha nekem olyan magyar beállí- 
tás kell, ami nem érzékeny a kis-nagybetűre, de megkülön- 
bözteti az ékezeteket (ez a tipikus beállítás), akkor a Hun- 
garian CI AS a nyerő választás. Valójában kétféle nyelvi 
konstans csoport is van, az egyik a Windows 2000 által is 
biztosítottakkal azonos, a másik rész pedig csak az SOL Ser- 
ver által biztosítottak. Ezeket legtöbbször csak a régi SOL 
Serverekről történő frissítés során használjuk, az ajánlott 
(és sokkal bővebb) az első csoport. 


Nyelvi csatározások 

Mi van akkor, ha egy tábla különböző oszlopaiban különböző 
nyelveken írt szövegeket szeretnénk tárolni, az adott nyelv- 
nek megfelelően sorbarendezni, kezelni? Az egyik oszlopban 
egy kis magyar szöveg, a következőben német, satöbbi. Ter- 
mészetesen ennek semmi akadálya, köszönhetően annak, 
hogy akár oszlopszinten megmondhatjuk a nyelvi beállításo- 
kat. Azonban ez jó kis kalamajkákhoz tud vezetni, amint va- 
lamilyen módon kapcsolatba kerülnek egymással. 

Ha különböző collation-ű oszlopokat akarunk összehasonlíta- 
ni (csz), akkor gondok lesznek, hisz melyiken értelmezett 
beállításokat, pl. kis-nagybetű érzékenységet vegye figye- 
lembe az SOL Server? Ugyanez a kérdés jön elő különböző 
nyelvű szövegek összefűzésénél (--) is. Magyart a héberrel 
összehasonlítani semmi értelme, de pl. jól jöhet az, hogy egy 
oszlopban tárolt szöveg ékezetre érzékeny beállítású, míg 
egy másik nem, és ezeket szeretnénk összehasonlítani vala- 
mely módon, például ékezetek nélkül. Ami még ennél is gya- 
koribb, hogy az összehasonlítások során hol érzékenynek kell 
lenni a kis-nagybetűre, hol nem. Ilyenkor jön jól a COLLATE 
kulcsszó, amellyel igazságot lehet tenni. Ám előbb nézzük 
meg, hogy a különböző helyekről jövő nyelvi beállításoknak 
mekkora a prioritása egymással szemben. 

Ha egy beépített függvény szöveget ad vissza (pl. 
USER NAME), akkor annak a collation-je az aktuális adatbá- 
zisra (amiben a felhasználó van) alapértelmezett beállítás 
lesz. Ez a leggyengébb prioritású. 

Adatbázisoszlopra történő hivatkozásnál, az oszlop adatbá- 
zisból örökölt vagy a tábla létrahozásakor megadott nyelvi 
beállítás lesz az alap. 

Ha egy kifejezésben (például két szöveg összehasonlítása) expli- 
cit megadunk egy collation-t valamelyik szövegre, akkor általá- 
ban annak lesz a legnagyobb prioritása. 

Nézzük meg az előbbieket egy példán keresztül! Készítsünk egy 
táblát, amelynek két oszlopa van, mindkettő magyar beállítá- 
sokkal, de az egyik kis-nagybetű érzékeny, a másik nem. 


CREATE TABLE Comp 
( 
HCI varchar(50) 
COLLATE SOL Hungarian CP1250 CS AS NOT NULL, 
HCS varchar(50) 
COLLATE SOL Hungarian CP1l250 CI AS NOT NULL 


) 


Szúrjunk be egy tesztsort, és próbáljuk meg összehasonlíta- 
ni a két oszlopot! 
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INSERT Comp (HCI, HCS) 
VALUES ("Netacademia", "NetAcademia!") 


--Teszt egyenlőségvizsgálat 
SELECT 
CASE 
WHEN HCI - HCS THEN 
"Egyformák" 
ELSE 
"Különböznek" 
END, 
HCI, 
HCS 
FROM 


comp 
Az összehasonlítás helyett egy csúnya hibaüzenetet kapunk: 


Server: Msg 446, Level 16, State 9, Line 1 
Cannot resolve collation conflict for egual to 


operation. 


Az a problémája az SOL Servernek, hogy össze akarunk ha- 
sonlítani két oszlopot, amelyeknek nem azonos a collation- 
je. Ez önmagában még nem volna probléma, csakhogy az 
egyenlőség mindkét oldalán oszlop-hivatkozás található, 
így a prioritások alapján nem lehet eldönteni az összeha- 
sonlítás kivitelezéséhez szükséges kis-nagybetű érzékeny- 
séget, mert a két oldal egyforma prioritású. 

Mit lehet tenni? Egyrészt megmondhatnánk kiszolgálónak, 
hogy a jobboldali oszlop, amely egyébként kis-nagybetű ér- 
zékeny, ne legyen az. Így megszűnik a konfliktus oka, hisz 
a kifejezés mindkét fele azonos collation-ű lesz: 


CASE 
WHEN HCI 5 
HCS COLLATE SOL Hungarian CP1l250 CI AS 


Az eredmény az elvárt lesz, azaz a két oszlop megegyezik, 
mert kis-nagybetűre nem érzékeny collation-t választottunk 
közös nevezőnek: 


Egyformák Netacademia NetAcademia 


Aki szereti a konfliktust, annak ajánlok egy másik megol- 
dást. Melyik konstrukciónak is volt a legnagyobb prioritá- 
sa? Hát az explicit COLLATE parancsnak. Mondjuk azt, hogy 
tudjuk, hogy a jobb oldali oszlop Case Sensitive, és ezt sze- 
retnénk megerősíteni egy COLLATE-el is. Ekkor ez ellent- 
mondás lesz a HCI oszlop által dirigált Case Insensítivity- 
vel szemben, de hát győz az erősebb: 
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CASE 
WHEN HCI - 


HCS COLLATE SOL Hungarian CP1l250 cs AS 


Különböznek Netacademia NetAcademia 


A nyelvi beállítások miatti ütközéseknek, lehetséges konf- 
liktusoknak most csak egy részét elemeztem ki. Részletes 
információt velük kapcsolatban a BOL-ban, a Collation Pre- 
cedence címszó alatt találhat a Kedves Olvasó. 


EZEKTŐL A RÖVIDÍTÉSEKTŐL 
HANGOS A SZAKMA. 

MINDEN MAGÁRA VALAMIT IS 
ADÓ RENDSZER EZEKRE 


A TECHNOLÓGIÁKRA ÉPÍT. 


ÖN FELKÉSZÜLT MÁR 


A KIHÍVÁSRA? 


BŐVEBB INFORMÁCIÓ: HTTP://WWW.NETACADEMIA.NET/COURSES/1905.ASP 


TRANSACT SOL (VII. RÉSZ) 
Zárszó 

Az előző Tech.net számban kimaradt egy rész a Transact 
SOL sorozatból. Sok visszajelzést kaptam, amelyekben hiá- 
nyolták az aktuális havi SOL Server evangéliumot. Köszö- 
nöm a dicsérő szavakat. Minden lelkes SOL Server rajongó- 
nak üzenem, hogy amíg lesz tinta a billentyűzetemben, 
addig lesz SOL sorozat is. A pozitív visszajelzések jót tesz- 
nek a töltőtollamnak, a kritikák pedig segítenek abban, 
hogy a sorozat még jobb legyen, és még inkább arról szól- 
jon, ami segítik az Önök mindennapi munkáját. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.net 


5 NAPOS INTENZÍV 
XML TANFOLYAMUNKON NAPRAKÉSZ, 
AZONNAL ALKALMAZHATÓ XML 


TUDÁSRA TEHET SZERT. 





A legjobbakat tanítjuk. 
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K: Hogyan lehet Telnet ablakból teljes értékű email írni? Csak 
kíváncsiságból. . . 

V: Aki eddigi cikkeinket elolvasta e tárgyban, az már majd- 
nem tudja is. Így: 


TELNET MAIL.AHOL.COM 25 
(Az ahol.com tényleg SMTP Server, de ez csak példa!) Ezután 


az adott kiszolgáló üdvözlő üzenetét láthatjuk, és kezdhet- 
jük a levél írását. 


(EL: 





0 Email by hand 

Először illedelmesen köszönünk: 

EHLO 

Azután megadjuk a feladót a borítékon: 

MAIL FROM: afa.a 

Majd a címzett címe következik: 

RCPT TO: valakiégnetacademia.net 

A DATA parancs után jön a levél: 

DATA 

A levélen belül ismét megadható a feladó és a címzett: 
From: Mikulas 

To: Valaki Samuel 

Subject: semmi 

Nagyon fontos a Subject utáni üres sor! Majd jöhet a szö- 
veg. Legyen - mondjuk - plain text, mert mást úgysem tu- 


dunk kézzel írni: 


Tisztelt Valaki! 
Ezuton blablabla... 
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Az egyetlen pontot tartalmazó sor indítja be a levélküldés 
folymatát: 


250 2.6.0 
SLPLATANxjUijgwbd0000000Oléplatan.netacademia.net: 
Oueued mail for delivery 


Vigyázat! Rontási lehetőség nincs, a BackSpace és a törlő- 
gomb használata nem a kívánt hatással jár, hanem az adott 
billentyűnek megfelelő ASCII kód bekerül a parancsokba! 
Aki félregépelte, kezdheti elölről! (Az Outlook kicsivel ké- 
nyelmesebb nem?) 

Forrás: NetAcademia Exchange 2000 lista 


K: Hogyan lehetne olyan scriptet írni Exchange 5.5-re, ami nem 
aszinkron módon fut? Mert most az a baj, hogy mire lefut, már 
lehet hogy törölték az üzenetet, amin dolgoznia kellene. . . 

V: Upgrade to Exchange 2000. Részletesebben: szinkronmű- 
ködésű scriptet az Exchange 5.5 nem tud. 

Forrás: NetAcademia Exchange 2000 lista 


K: Az a problémám, hogy egy tagkiszolgálót ki szerettem vol- 
na nevezni tartományvezérlővé, s ennek érdekében lefuttat- 
tam a DCPROMO.EXE-t, de sajnos az Active Directory telepíté- 
se nem sikerült. Ennél is szomorúbb, hogy most a gép nem 
tartományvezérlő, sem tagkiszolgáló többé, hanem félúton 
van. Nosza, ráeresztettem a DCPROMO-t mégegyszer, hogy 
visszavigyem a kiindulási állapotba — nem sikerül. Safe Mode 
sem segít. Az operációs rendszer újratelepítése sem túl jó öt- 
let. Most mi lesz? 

V: Ilyen esetekben a következőt kell tenni: egy ügyes regist- 
rymódosítással kell kibillenteni a gépet jelenlegi lehetetlen 
helyzetéből. Ha a 


HKEY LOCAL MACHINENSYSTEM(CurrentControlsSett 
0 ControllProductoptions 


kulcs alatti ProductType értékét átírjuk ,LanmanNT"-ről 
sServerNT"-re, akkor a következő újraindításnál az LSASS.EXE 
(Local Security Authority) nem húzza be az Active Directoryt 
a memóriába, hanem standalone üzemmódban indul. Ezzel 
már vissza is tértünk a tagkiszolgálóhoz. Már csak a 
WINNTWTDS könyvtár törlése van hátra, és a DCPROMO in- 
dulhat is, ismét nulláról! 

Forrás: NetAcademia Windows 2000 lista 


K: Van egy Win2000-es gép, amelyen azt szeretném beállíta- 
ni, hogy a felhasználók ne tudjanak napközben ezen keresz- 
tül felcsatlakozni az Internetre, hanem csak a kedvezményes 
időszakban legyen erre lehetőségük. A legtökéletesebb megol- 
dás az volna, ha a felhasználók közül néhányat ki tudnék je- 
lölni, akikre nem érvényes ez a korlátozás. 
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Jogosultságokkal el tudom érni ezt az állapotot, de sajnos 
nem tudom megoldani, hogy a kedvezményes időszak kezde- 
tekor automatikusan engedjen mindenkit. Külön gond, hogy 
a kedvezményes időszakok másként alakulnak hétvégén és 
hétköznap. Milyen szoftver oldaná meg a problémámat? 

V: A Windows 2000-be beépített RAS szolgáltatás pont er- 
re való. A hozzá tartozó házirend (policy) kismillió beállí- 
tása között megtalálható a kapcsolatengedélyezés időabla- 
ka is, amelyet az alábbi ábrán rendesen ,testreszabtam": 


Tíme of day constraints fsz xx 








Tuesday írom 11 AM to 12 PM 





a Kedden délelőtt 11-kor például szabad tárcsázni... 


Ez még kevés lenne a boldogsághoz, mert személyenként 
különbözőképpen kellene beállítani. Ehhez további policy- 
kat kell felvenni, melyekben természetesen az érintett fel- 
használók mások lesznek, ezt különböző csoportok felvéte- 
lével érhetjük el. Hab a tortán, hogy a házirend által enge- 
délyezett kapcsolatokat a házirend profilja menet közben 
tudja vezérelni, adott esetben például megszakítani, vagy 
egynél több modemet egyidejűleg használni. 

Forrás: NetAcademia Windows 2000 lista 


K: Adott egy tárolt eljárás, aminek a visszaadott eredmény- 
halmazán, mint recordset-en további lekérdezéseket szeret- 
nék futtatni. Van erre lehetőségem SOLServer 7 alatt? 

V: Első ránézésre a dolog SOL 2000 után kiált, de van le- 
hetőség, mégpedig a következő trükkös módon: használd 
az OpenRowsSet függvényt, mellyel a saját SOL Serveredhez 
kapcsolódsz, mintha az egy Linked Server lenne. 


select t from openrowset( "SOLOLEDB", serv name"; 
0 "sa"; "", "exec sp who" ) where status - 


0 "sleeping" 


Forrás: NetAcademia SOL 2000 lista 
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K: Az AT parancsot használnám batch parancs futtatására, 
fájlok mentésére úgy, hogy közben lássam is, mi zajlik, de a 
/INTERACTIVE kapcsoló hol működik, hol nem. Mi a baj? 

V: A /INTERACTIVE kapcsoló trükkös nem működésének az 
az oka, hogy NEM MINDEGY, hogy az AT parancsba hova ír- 
juk be, csak azon a pozíción működik, ahol az AT /? mond- 
ja! A többi esetben, pl. ha a a parancs végére írjuk, min- 
denféle hibaüzenet nélkül, csendben nem működik, és az 
időzített parancs nem jelenik meg a felhasználói felületen, 
hanem rejtve fut... 

Forrás: NetAcademia Windows 2000 lista 


K: Mire jó a READ jog hiánya? Úgy vettem észre, az Active 
Directoryban a READ jog nem egészen úgy vislekedik, mint 
például az NTFS-en. 

V: Jogos észrevétel. NTFS esetén a READ jog hiánya nem 

tünteti el a szemem elől az érintett fájlokat és könyvtára- 

kat (pedig de jó lenne, ha így működne!) , hanem csak a tar- 
talma olvashatatlan. Ha megpróbálom megnyitni, jön az 

Access Denied" móka. 

Ám az Active Directoryban másképp van! 

A READ jog hiánya nem feltétlenül , Access Denied" hatás- 

sal jár, hanem egyéb funkciók ellátására is való! Példák: 

1) Active Directory: ha nincs READ jogunk egy objektu- 
mon (felhasználó, szervezeti egység stb.), akkor nem is 
látjuk az objektumot/konténert a címtárban (á la no- 
vell). Itt a READ jog megvonása a láthatósággal van 
kapcsolatban. 

2) Group Policy: ha nincs READ és APPLY joga egy felhasz- 
nálónak egy GPO objektumon, akkor nem hibaüzenetet 
kap, hanem nem értékelődik ki rá a házirend. Vagyis a 
READ (és/vagy APPLY) jog megvonásával lehet kivételt 
képezni a házirend hatása alól. 

3) Remote Installation Services: ha az Unattend.TXT fájl- 
on nincs READ jogunk, ennek az lesz a hatása, hogy az 
adott telepítési lehetőség nem jelenik meg a RIS ügy- 
félképernyőjén a telepítési lehetőségek felsorolásában. 
Ebben az esetben a READ jog megvonása a felhaszná- 
lók számára felkínált RIS telepítési lehetőségek, menü- 
pontok korlátozására való. 

Forrás: NetAcademia Windows 2000 lista 
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Pazarló világban élünk, és a pazarlás bűn. Különösen az egy 
olyan világban, ahol az a szűkös erőforrásokat (például a 
sávszélességet, a tárkapacitást, a processzoridőt, a mi drága 
időnket stb.) érinti. Az egymást gerjesztő hardver- és szoft- 
sorolhatnám. Ehelyett inkább hadd ragadjak meg egyetlen 
példát, a weboldalak ékesítésének szinte már nélkülözhe- 
tetlen eszközét: a képet. 

Egy digitális kép parányi négyzetekből, képpontokból áll, 
melyek mindegyikéhez egy véges halmazból választható 
szín. Szorozzuk össze a vízszintes és a függőleges felbon- 
tást a színmélységgel! Az eredmény a kép tárolásához szük- 
séges hely. Bocsánat, hadd javítsam ki magam: az ered- 
mény a kép tárolásához elégséges hely. Nem túl brilliáns 
módszer, ugye? Biztosan mindenki hallotta már a követke- 
ző rövidítéseket: JPG, GIF, TIF, PXC, PNG hogy csak a legis- 
mertebbeket említsem. Nincs varázslat, csak tömörítés. A 
különféle módszerek hatékonyságát megítélni nem egysze- 
rű feladat, mivel a legtöbbnél nemcsak a méret változik, 
hanem a minőség is (ellentétben azokkal a képtömörítő el- 
járásokkal, amelyek kizárólag a redundancián alapulnak). 
Az Internet egyik nagy kedvence a Joint Photographic Ex- 
perts Group által kifejlesztett JPG (a 8.3-as fájlnévkorszak 
hanyatlása után egyre gyakrabban JPEG) , amely nagyon jó 
színhűséggel ábrázolja az eredeti képet, kis helyen. A 
trükk az, hogy a képet 8x8 képpont nagyságú négyzetek- 
re bontják, amiből a túl sok helyet foglaló, de a minőség 
szempontjából kevésbé lényeges színinformációt egy DCT 
nevű transzformációval kiszűrik. (Ha nem hiszi, töltsön be 
egy JPEG képet, nagyítsa fel a kétszeresére vagy a négysze- 
resére, és meglátja a normál méretnél szinte észrevehetet- 
len négyzethálót. Ha a program alkalmas rá, a négyzetek 
méretét is ellenőrizheti.) A DCT a képeknek elsősorban 
azon részeit érinti hátrányosan, ahol a színek hirtelen vál- 
toznak. A kép darabos lesz, viszont kárpótlásul nem kell 
sokat várni, hogy a grafikai elemek megjelenjenek a letöl- 
tött weboldalakon. Mondhatjuk, hogy a JPEG megfelel a 
célnak? Mondhatnánk. Én viszont azt mondom, hogy a 
JPEG pazarlás. Miért? Mert van jobb! 

A tömörítési algoritmusok fejlődése csodákra képes. Jobb 
minőség kisebb helyen - akár egy marketing doksiban. A 
Microsoft jelfeldolgozási csoportjának vezetője, Henrigue 
Rico" Malvar olyan kódolási szabványt dolgozott ki, amely 
a JPEG-nél gyorsabb és hatékonyabb tömörítést tesz lehe- 
tővé. Az algoritmus neve Progressive Wavelet Codec (PWC). 
A Wavelet Codec kifejezés egy sor kódolási megoldást ta- 
kar, de a PWC kitűnik közülük egyszerűségével, gyorsasá- 
gával és skálázhatóságával. 

A PWC kép minősége önmagában nem csúcs, de a JPG-vel 
összehasonlítva óriási előrelépés. Szebb vonalvezetése annak 
köszönhető, hogy a képet a valódi kontúrokat követő, külön- 
féle méretű ívek építik fel, nem pedig a szem érzékenységé- 
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hez képest nagy négyzetek. Míg a JPG esetében az éles kon- 
túroknál nagyon , bolyhos" lesz a kép, ugyanennek a PWC kó- 
dolású változata sokkal kellemesebb látványt nyújt. 
A PWC tömörítés rugalmas és robusztus képkezelést bizto- 
sít. Másképpen fogalmazva: egyrészt veszteséség nélkül tö- 
mörít - legalábbis ami a színeket illeti, - másrészt adott 
felbontás és élethűség mellett tömörített kép dekódolása 
kisebb felbontásnál és élethűségnél is elvégezhető. Nincs 
szükség tehát arra, hogy az átméretezésnél először az erede- 
ti paraméterekkel dekódoljunk, majd az újakkal ismét kódol- 
junk, az új beállítások azonnal érvényesíthetők a dekódolá- 
si folyamatban. Azok, akik készítettek már weboldalt, bizto- 
san tudják, milyen nehézkes tud lenni a JPEG képek keze- 
lése. A PWC többek között náluk is nagy sikerre számíthat. 
Képzeljünk el egy 10 Mbps-es helyi hálózatot, amelyhez 
modemmel is lehet kapcsolódni a nyilvános telefon-hálóza- 
ton keresztül. Az utóbbi esetben szerényebb átviteli sebes- 
séggel, mondjuk 33,6 Kbps-sel kell beérnünk. Ki tölti le ha- 
marabb ugyanazt a hagyományos képekkel teletűzdelt web- 
oldalt? Időm se nagyon lenne kimondani, hogy rajt, és az 
első versenyző már célba is ért. Ez a küzdelem nem felelt 
meg a fair play szabályainak. De fog, ha segít a PWC első 
betűje mögé rejtőző progressive (fokozatos) jelző. 
A fokozatos kódolás a képet ún. rétegekre bontja, amely- 
ből mindenki a maga erejének megfelelő mennyiséget 
tölthet le. Magától értetődő, hogy a LAN-os versenyző ké- 
pei szebbek lesznek, de nem lepődnék meg, ha a modemes 
résztvevő azt mondaná: nem annyival, amennyivel a letöl- 
tést gyorsabban befejeztem! 
A PWC ennek a technikának valójában egy sajátos és különö- 
sen hasznos formáját, a beágyazott kódolást alkalmazza. Az 
előzőhöz képest többletet az jelenti, hogy a képet leíró bit- 
sorozatokból elegendő csak akkora, az erőforrásainknak meg- 
felelő előtagot figyelembe venni (letölteni), amekkorát adott 
felbontás, illetve élethűség megkíván. 
A kutatók - és most már valószínűleg az olvasók is - bíznak 
benne, hogy a PWC kiterjesztést hamarosan egyre több kép- 
szerkesztő program és böngésző ismeri majd fel. Az ered- 
mény: takarékosság a sávszélességgel, a tárhellyel, javul a 
weboldalak letöltésének sebessége, és ami legalább ennyire 
fontos, mindez nem a képek minőségének a rovására, hanem 
épp ellenkezőleg, a vizuális élvezet fokozásával válik valóra. 
Úgy legyen! 
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A ,tech.net magazin Brainstorm" a Dupla KV rovathoz hasonló, ám a személyes 
kérdésfelvetést és vitát is lehetővé tevő rendezvény, melynek célja 


e Az elsőre talán ismeretlen technológiák élő bemutatása 
e A cikkekhez kapcsolódó kódok megírása/kipróbálása 
o A terjedelmi okokból kimaradt információk átadása 


E magazinnal együtt a legelső rendezvényre érvényes belépőjegyet minden előfize- 
tőnkhöz eljuttattuk. 
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. (Bár belépőjegyet adtunk, ez a tény önmagában nem biztosítja helyét a rendezvényen. A jegy célja előfizetőink elsődlegességének biztosítása, de a korlátozott 
résztvevői létszám (100 fő) miatt a regisztráció kötelező. Jelentkezzen, amíg nem késő!) 
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